https://bugzilla.novell.com/show_bug.cgi?id=681109 https://bugzilla.novell.com/show_bug.cgi?id=681109#c4 Stanislav Brabec changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW CC| |puzel@novell.com InfoProvider|sbrabec@novell.com | --- Comment #4 from Stanislav Brabec 2011-05-13 15:06:08 CEST --- My clock are set to UTC and I don't need anything else than setting SYSTZ in kernel. In my opinion, mount utility does not use SYSTZ kernel setting nor /etc/localtime nor TZ system variable. It just passes mount options to the kernel and kernel plays on its own. Petr, could you confirm it? mount utility does not play with SYSTZ at all and the kernel has only two possibilities with the FAT based file systems: - no special option: kernel expects that this FAT file system uses local time and uses SYSTZ kernel setting for time stamps - tz=UTC: kernel expects that this FAT file system uses UTC and does not manipulate with time stamps As far as I know, only hwclock --systz and wrapclock manipulate with SYSTZ kernel setting. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=681109 https://bugzilla.novell.com/show_bug.cgi?id=681109#c6 Stanislav Brabec changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |mmarek@novell.com Resolution|INVALID | AssignedTo|werner@novell.com |kernel-maintainers@forge.pr | |ovo.novell.com Summary|/etc/init.d/boot.clock: |FAT timestamp shift |SYSTZ is not set properly | |under some conditions | --- Comment #6 from Stanislav Brabec 2011-05-13 18:35:11 CEST --- Maybe the request to change the init script is invalid, but the FAT time offset problem is valid. At least some devices are using FAT with local time. My camera uses local time (otherwise Windows users see bad time stamps). My system time is set to CET/CEST using /etc/localtime. I want to mount my camera. - With a bare openSUSE 11.4, I get two hours offset. - Calling of hwclock --systz --utc, unmounting and mounting again (using desktop mount) fixes that problem. No mount optios was changes. => Kernel apparently uses SYSTZ and not timezone of the mount utility environment. If SYSTZ is intended to set RTC time zone and not to set timezone of FAT filesystems, then it is probably bug in the kernel. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=681109 https://bugzilla.novell.com/show_bug.cgi?id=681109#c8 Stanislav Brabec changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED InfoProvider|sbrabec@suse.com | --- Comment #8 from Stanislav Brabec 2011-09-01 16:05:09 CEST --- Kernel cares about timezones in several places: - kernel/time.c Setting system clock during boot. - file systems: Setting file times for file systems that use local time (FAT and others). - Several SCSI and net drivers. According to the discussion above, it is a bad idea to share the same variable for setting system time from hwclock and define file system times offset. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=681109 https://bugzilla.novell.com/show_bug.cgi?id=681109#c10 --- Comment #10 from Stanislav Brabec 2012-06-26 17:01:40 CEST --- I understand that. But according to the comment 5, sys_tz is also used for hwclock time offset. It makes a clash: - If hwclock is in UTC, but you want to mount FAT with the default kernel-global (local) timezone. - If hwclock is in the local time, but you want FAT with UTC. Well, I also failed to use FAT with DST-wise times. Calling hwclock --systz causes times shift of all files on all FAT volumes whenever DST time is activated or deactivated. That is why I suspect that kernel does not fully support time zones, but only an time stamp shift. (I know, that the conversion from local time to UTC cannot be done completely, but at least 99.98% files could have true and constant time stamp.) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=681109 https://bugzilla.novell.com/show_bug.cgi?id=681109#c11 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO InfoProvider| |kkzhang@suse.com --- Comment #11 from Dr. Werner Fink 2012-07-20 07:18:58 UTC --- Why I've assigned to this bug? I'm not maintainer of the FAT file system. Beside this: The kernels system clock is UTC. If CMOS is in UTC all is OK. If CMOS is not in UTC the kernel has to be informed by warpclock utility or with hwclock using the --systz option. This is *not* triable as file system check and mounting the root file system depend on the correct time stamps even within initrd *before* accessing the root file system. Also: do *never* change the kernels assumption about CMOS clock to a wrong assumption, that is it CMOS is in UTC do not use warpclock or hwclock --systz to displace the internal system clock. Otherwise the not only the system clock is wrong but also the user space clock is definitly wrong. An other question rises: Why this does not happen with my memory sticks nor with my digital cameras? On of them using FAT CF and on of them with a SD accessible only with gphoto2? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=681109 https://bugzilla.novell.com/show_bug.cgi?id=681109#c13 --- Comment #13 from Stanislav Brabec 2012-07-20 17:14:01 CEST --- If your camera time is set to the local time and uses FAT, then it probably happens as well. I see this problem on all my cameras. (I never seen a camera that allows to set time and time zone.) The time in EXIF is true local time. The time stamp of the file is shifted by two hours (my time zone is CEST). To partially work-around this problem, I use "hwclock --systz". It fixes mtime of photos taken in the current half year, but introduces unwanted shift for photos taken before DST became active. (Kernel is not aware of DST.)) The same problem happens with my Android phone: Before "hwclock --systz": sbrabec@oct:/run/media/sbrabec/4E4D-C320/DCIM/100MEDIA> exiftool IMAG0055.jpg | grep -i time File Modification Date/Time : 2012:07:13 18:01:26+02:00 Date/Time Original : 2012:07:13 16:01:21 GPS Time Stamp : 14:01:21 GPS Date/Time : 2012:07:13 14:01:21Z File Modification Date/Time is an apparent nonsense. After "hwclock --systz", unmounting and mounting again: sbrabec@oct:/run/media/sbrabec/4E4D-C320/DCIM/100MEDIA> exiftool IMAG0055.jpg | grep -i time File Modification Date/Time : 2012:07:13 16:01:26+02:00 Date/Time Original : 2012:07:13 16:01:21 GPS Time Stamp : 14:01:21 GPS Date/Time : 2012:07:13 14:01:21Z Mount options: gvfs-fuse-daemon on /run/user/sbrabec/gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,relatime,user_id=10027,group_id=100) /dev/sdb1 on /run/media/sbrabec/4E4D-C320 type vfat (rw,nosuid,nodev,relatime,uid=10027,gid=100,fmask=0022,dmask=0077,codepage=cp437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,errors=remount-ro,uhelper=udisks2) Android (2.3.3 in my phone) itself is partially affected as well: sbrabec@oct:~> adb shell $ ls -al /mnt/sdcard/DCIM/100MEDIA/IMAG0055.jpg ----rwxr-x 1 1000 1015 595485 Jul 13 14:01 /mnt/sdcard/DCIM/100MEDIA/IMAG0055.jpg (The date is in UTC, Android does not install timezone package used by busybox.) Ghost commander shows 14:01 as well. Image Gallery and QuickPic show 16:01 (probably from EXIF.) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=681109 https://bugzilla.novell.com/show_bug.cgi?id=681109#c15 --- Comment #15 from Dr. Werner Fink 2012-07-20 15:35:31 UTC --- (In reply to comment #13) The kernels clock (which is the system clock) is in UTC and there is no DST defined (therefore it is called Universal Time Coordinated). The DST rules in user space come into account with /etc/localtime and can be overridden by using the TZ environment variable. Now if you are using `hwclock --systz' ther kernel clock isn't in UTC anymore but the kernel does use this new clock as ``UTC'' and with this the user space time defined by /etc/localtime or TZ environment variable becomes wrong. And you can not go back anymore as the systz is a oneway, compare with the manual page of settimeofday(2) (search for tz_minuteswest) or read my comments in warpclock.c you can found in the source package mkinitrd. I sugggest to use the TZ environment variable which if set may correct for a specific session the timeoffset. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=681109 https://bugzilla.novell.com/show_bug.cgi?id=681109#c17 --- Comment #17 from Stanislav Brabec 2012-08-29 17:27:34 CEST --- Well, if you do not want to embed (local) time to the camera image, setting camera time to UTC (and optional EXIF time shift to local time in exiftool) is a smart solution. But I think that file interchange with Windows users would need local time (I do not have any Windows system to test it). Jan Kara: Thinking deeper about it: How complicated would be making of user space hook API for file header manipulation? I can imagine, that this API could: - Handle file system stamps (DST and time zone wise conversion to UNIX time stamp). - Handle mapping of long names to short names (VFAT to 8+3 and Joliet to RR and RR to 8+3). - Compare file names in open() and tell whether they are the same (locale-wise case insensitive comparison). - Access to other special attributes. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=681109 https://bugzilla.novell.com/show_bug.cgi?id=681109#c19 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|werner@suse.com | --- Comment #19 from Dr. Werner Fink 2012-10-01 13:08:04 UTC ---

So it seems possible to have CMOS clock in UTC and kernel sys_tz set to -120 as you need. Werner?

This is possible but this is IMHO a nogo as the time reference is UTC in the kernel's system clock anf you would fool not only the kernel. This also would lead definitly to a wrong clock in user space as all zoneinfo file are gauged on UTC which is determined by using time(2) system call. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=681109 https://bugzilla.novell.com/show_bug.cgi?id=681109#c21 Jan Kara changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P4 - Low Status|ASSIGNED |NEEDINFO InfoProvider| |sbrabec@suse.com --- Comment #21 from Jan Kara 2012-10-01 20:47:51 UTC --- Setting needinfo for a patch. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=681109 https://bugzilla.novell.com/show_bug.cgi?id=681109#c23 Stanislav Brabec changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|sbrabec@suse.com | --- Comment #23 from Stanislav Brabec 2012-10-22 16:05:00 CEST --- Yes, use the current timezone as default would be much better than using SYSTZ as default. But not perfect, as it does not solve DST problem. I am often using rsync from VFAT systems, and when DST change occurs, rsync copies the whole tree again. Thinking again about it, UTC may be much smarter default (in kernel and/or mount). (And it seems, that it is a default on Android as well, so phone photos will not have shifted time stamp in the ideal case. Needs test.) As an alternative to comment 17, it would be easy to write a FUSE module, that is transparent for files, and just performs time stamp shift, with respect to time zone and DST. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=681109 https://bugzilla.novell.com/show_bug.cgi?id=681109#c25 --- Comment #25 from Jan Kara 2012-11-21 01:39:28 UTC --- Just for info, patch (in somewhat changed form) is now bubbling through maintainer trees into upstream. I'll now have a look into modifying mount(8) to pass proper mount option automatically. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=681109 https://bugzilla.novell.com/show_bug.cgi?id=681109#c27 --- Comment #27 from Stanislav Brabec 2012-11-22 15:17:05 CET --- time_offset=current (tz=current as addition to tz={number}) would make sense only if the default will be UTC. UTC as default (and ignoring systz) makes sense, because the behavior will be consistent on all systems and will not depend on value of systz (i. e. hardware clock offset). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=681109 https://bugzilla.novell.com/show_bug.cgi?id=681109#c29 --- Comment #29 from Stanislav Brabec 2012-11-23 16:57:53 CET --- Well, tz=current would behave a bit better than the current default. But I see no fully correct solution. It is a question, how tz=current will handle DST. Either - Add DST offset to time zone offset. It will make mtime of recent files correct, but all files change mtime during the first mount after DST change. or - Ignore DST at all. Files will have stable mtime, but all files created during the summer will be one hour off. Example of failing backup strategy: Using rsync --modify-window=2 to the VFAT USB dongle. The dongle can be connected to several machines. Sometimes it is connected locally, sometimes remotely. The current default: It will copy all files instead of changes only every time you move the dongle from machine with Windows (i. e. RTC in local time) to machine without Windows installed (i. e. RTC). It will also copy all files whenever DST change occurs. Times of files created in summer are one hour off in the winter and vice versa. tz=current (respecting DST): It will copy all files instead of changes only every time DST change occurs. Times of files created in summer are one hour off in the winter and vice versa. tz=current (ignoring DST): It will never copy all files instead of changes only. But times of files created in summer are be one hour off comparing to Windows (or say camera). tz=utc: It will never copy all files instead of changes only. But if UTC is not your native time zone, times of files will be always off comparing to Windows (or say camera). Note: Android is affected by this problem as well: This is a look at the photo taken with DST active time (at 12:12 UTC, which equals to 14:12 CEST), how it looks with DST inactive (CET): With tz=UTC sbrabec@oct:/mnt/DCIM/100MEDIA> exiftool IMAG0107.jpg | grep Time File Modification Date/Time : 2012:10:27 16:12:40+02:00 Date/Time Original : 2012:10:27 14:12:35 GPS Time Stamp : 12:12:35 GPS Date/Time : 2012:10:27 12:12:35Z With SYSTZ set to UTC (in winter): sbrabec@oct:/mnt/DCIM/100MEDIA> exiftool IMAG0107.jpg | grep Time File Modification Date/Time : 2012:10:27 15:12:40+02:00 Date/Time Original : 2012:10:27 14:12:35 GPS Time Stamp : 12:12:35 GPS Date/Time : 2012:10:27 12:12:35Z On Android (busybox shows times in UTC): sbrabec@oct:~> adb shell busybox ls -ale /mnt/sdcard/DCIM/100MEDIA/IMAG0107.jpg ----rwxr-x 1 1000 1015 1857885 Sat Oct 27 13:12:40 2012 /mnt/sdcard/DCIM/100MEDIA/IMAG0107.jpg -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=681109 https://bugzilla.novell.com/show_bug.cgi?id=681109#c31 Jan Kara changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|jack@suse.com | --- Comment #31 from Jan Kara 2013-11-22 18:47:21 UTC --- Well, it is basically unfixable problem in FAT disk format. Kernel FAT driver now has a mount option (time_offset=) with which you can specify offset of FAT time stamps from UTC (so that FAT doesn't rely on systz variable). We could have a mount.vfat handler which could set time_offset=<current zone offset> for kernel but as I wrote in comment 26, it could break some systems and as Stanislav examined in comment 29, there's no perfect solution - actually there is, don't use FAT :). So I didn't write the mount wrapper in the end as I'm not sure adding any magic automation into the mess will actually help anything. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.