Bug 802198 - Incorrect timestamps for VFAT
Summary: Incorrect timestamps for VFAT
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-12 02:52 UTC by Danny Ciarniello
Modified: 2012-10-12 16:46 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-10-07 22:48:54 UTC


Attachments (Terms of Use)

Description Danny Ciarniello 2012-03-12 02:52:07 UTC
Description of problem:
Timestamps for files on a VFAT-formatted flash card (such as one used in a digital camera) are mounted with UTC time rather than local time.

Version-Release number of selected component (if applicable):


How reproducible:
Always


Steps to Reproduce:
Mount a VFAT-formatted card (without tz option)
  
Actual results:
The file timestamps are displayed in UTC

Expected results:
The file timestamps should be in local time 

Additional info:

The mount man page states

"tz=UTC This  option  disables  the conversion of timestamps between local time (as used by Windows on FAT) and UTC (which Linux uses internally).  This is particularly useful when mounting devices (like digital cameras) that are set to UTC in order to avoid the pitfalls of local time."

This would imply that no conversions should be done if the tz option is not specified.  I. e. timestamps should be in local time.

Note that this worked as expected in Fedora 14.

Comment 1 Karel Zak 2012-03-26 09:28:41 UTC
(In reply to comment #0)
> The mount man page states
> 
> "tz=UTC This  option  disables  the conversion of timestamps between local time
> (as used by Windows on FAT) and UTC (which Linux uses internally).  This is
> particularly useful when mounting devices (like digital cameras) that are set
> to UTC in order to avoid the pitfalls of local time."
> 
> This would imply that no conversions should be done if the tz option is not
> specified.  I. e. timestamps should be in local time.
> 
> Note that this worked as expected in Fedora 14.

Hmm... sounds like kernel timezone is not set properly. Reassigning to systemd.

Comment 2 Michal Schmidt 2012-03-26 12:00:35 UTC
I see. fat.ko cares about sys_tz.

sys_tz is set by settimeofday(). systemd calls it once on boot only if the hardware clock is running in local time. The purpose of the call is to do the clock warp (a correction from local time to UTC).
We don't want to do the warp when the clock is in UTC. This report shows that we should however set sys_tz. So the solution for the !hwclock_is_localtime case could be to call settimeofday() twice:
First with tz.tz_minuteswest=0 in order to do a dummy warp (a NOP).
Second with the actual correct tz_minuteswest value to set sys_tz.

Is your RTC clock running in UTC? (What does the 3rd line in /etc/adjtime say?)

Comment 3 Danny Ciarniello 2012-03-26 15:28:52 UTC
Yes, my RTC clock is set to UTC.

Comment 4 Karel Zak 2012-03-27 10:35:44 UTC
Michal, see also bug #672194 ;-)

Comment 6 Lennart Poettering 2012-09-17 15:29:45 UTC
Kay, please set bugs that are fixed upstream but not yet fixed in Fedora to POST!

Comment 7 Fedora Update System 2012-09-20 19:56:33 UTC
systemd-190-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/systemd-190-1.fc18

Comment 8 Fedora Update System 2012-09-22 06:37:41 UTC
Package systemd-191-2.fc18, rtkit-0.11-3.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-191-2.fc18 rtkit-0.11-3.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14581/rtkit-0.11-3.fc18,systemd-191-2.fc18
then log in and leave karma (feedback).

Comment 9 Danny Ciarniello 2012-09-24 03:04:51 UTC
Is the fix going to be pushed to Fedora 17 as well?

Comment 10 Fedora Update System 2012-09-28 00:18:11 UTC
Package glibc-2.16-17.fc18, systemd-192-1.fc18, selinux-policy-3.11.1-23.fc18, rtkit-0.11-3.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glibc-2.16-17.fc18 systemd-192-1.fc18 selinux-policy-3.11.1-23.fc18 rtkit-0.11-3.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14581/selinux-policy-3.11.1-23.fc18,rtkit-0.11-3.fc18,systemd-192-1.fc18,glibc-2.16-17.fc18
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2012-10-01 20:10:49 UTC
Package glibc-2.16-17.fc18, rtkit-0.11-3.fc18, systemd-193-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glibc-2.16-17.fc18 rtkit-0.11-3.fc18 systemd-193-1.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14581/rtkit-0.11-3.fc18,systemd-193-1.fc18,glibc-2.16-17.fc18
then log in and leave karma (feedback).

Comment 12 Fedora Update System 2012-10-12 16:46:22 UTC
systemd-44-20.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/systemd-44-20.fc17


Note You need to log in before you can comment on or make changes to this bug.