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.
(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.
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?)
Yes, my RTC clock is set to UTC.
Michal, see also bug #672194 ;-)
http://cgit.freedesktop.org/systemd/systemd/commit/?id=72edcff5db936e54cfc322d9392ec46e2428fd9b
Kay, please set bugs that are fixed upstream but not yet fixed in Fedora to POST!
systemd-190-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/systemd-190-1.fc18
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).
Is the fix going to be pushed to Fedora 17 as well?
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).
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).
systemd-44-20.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/systemd-44-20.fc17