This doesn't look like a fault of the kernel but a user-space side setup issue.
I checked my machine here and confirmed that systemd sets the kernel time in UTC.
So, this is the expected behavior on the recent systems.  (Note that it's not about the system TZ, but the TZ the kernel keeps inside.)

Excuse me, but I don't see how you can call this "resolved invalid"
when:

(a) It wasn't reported as a kernel bug in the first place.  I assigned
it to "basesystem"; I don't know why that goes to kernel-maintainers.
But it's clearly a problem in mount.vfat, since that's where the
tz=UTC option is handled.

(b) The response doesn't actually address the issue, other than
pointing out that the kernel time is kept in UTC--which has been the
case in Unix-like systems at *least* since V6 in 1972, and in any case
is completely irrelevant to the bug.

(c) A simple test of copying a file to a USB drive (in a non-UTC
timezone) and then mounting the drive on a different system, such as
Windows or Mac, will show that the timestamp is *not* the local
timestamp but rather the UTC one, which is incorrect for many, if not
most, users.

(d) As pointed out in the original bug report, the tz=UTC option has
no inverse, which means that when mount defaults to that option, the
user has no way to suppress it.

(e) If tz=UTC is the default behavior, then the option would become
useless.  Except that there is clearly a use for setting a non-UTC
timezone.

Let's try again.  This *IS* a bug.  It's a bug in mount.vfat, and it's
probably best fixed upstream.  Calling it invalid doesn't make it so.

(In reply to Geoff Kuenning from comment #2)
> Excuse me, but I don't see how you can call this "resolved invalid"
> when:
> 
> (a) It wasn't reported as a kernel bug in the first place.  I assigned
> it to "basesystem"; I don't know why that goes to kernel-maintainers.
> But it's clearly a problem in mount.vfat, since that's where the
> tz=UTC option is handled.
> 
> (b) The response doesn't actually address the issue, other than
> pointing out that the kernel time is kept in UTC--which has been the
> case in Unix-like systems at *least* since V6 in 1972, and in any case
> is completely irrelevant to the bug.
> 
> (c) A simple test of copying a file to a USB drive (in a non-UTC
> timezone) and then mounting the drive on a different system, such as
> Windows or Mac, will show that the timestamp is *not* the local
> timestamp but rather the UTC one, which is incorrect for many, if not
> most, users.
> 
> (d) As pointed out in the original bug report, the tz=UTC option has
> no inverse, which means that when mount defaults to that option, the
> user has no way to suppress it.
> 
> (e) If tz=UTC is the default behavior, then the option would become
> useless.  Except that there is clearly a use for setting a non-UTC
> timezone.
> 
> Let's try again.  This *IS* a bug.  It's a bug in mount.vfat, and it's
> probably best fixed upstream.  Calling it invalid doesn't make it so.

It's no bug of mount.vfat (at least no regression), and no bug of kernel itself.

The reason of the different behavior is the kernel TZ setup.  Now systemd sets it to UTC.  This makes thing easier, so it's fine per se.  However, the problem happens because some rest (including users :) expect the local TZ.  The kernel fat fs also handles the time based on the kernel TZ unless the options is given (what else can it refer to?).

A possible fix would be either:
- pass time_offset option corresponding to the local TZ in mount.vfat as default, or
- don't use UTC for kernel system TZ in systemd

IMO the former is a safer option.

About why kernel TZ setup was disabled by systemd, read the following:
  https://www.libreoffice.org/bugzilla/show_bug.cgi?id=81538

That said, this is a thing to be classified as the expected behavior change rather than a bug.  I do agree, though, that it's very little informed and covered, especially with a lack of counterpart to set the local TZ as you mentioned.

BTW, you can still set like "mount -otime_offset=480 /dev/sdb1 /mnt".  But it's not intuitive, and should be handled better.

And you may wonder why no tz=LOCAL is present: implementing it isn't trivial because the mount option is handled by the kernel, and the kernel has no idea about what's the local time.

Takashi, I appreciate the explanation and the link to 912583, even
though the reasoning used in that report, especially comment 5, is
clearly flawed.  (The general approach of "everybody in the world
should change their behavior to match my idea of how things should
have been in the first place" is both arrogant and foolish even when
driven by difficult design issues.)

You are correct that -otime_offset=480 is nonintuitive.  It is also,
as far as I can tell, utterly undocumented (it's not in any
mount-related man page, and there is no man page for mount.vfat).

It's also trivially obvious that if mount can implement -otime_offset,
it can equally well implement -tz=LOCAL or -tz=Europe/Berlin or
whatever else the user wants.  All it has to do is look up the zone
and insert whatever offset is approprite.  (Like -otime_offset, this
approach doesn't deal well with mounts that last across DST changes,
but that's a small price to pay for getting correct interoperability
with other systems.)

Honestly, I have currently no time to look into this bug. You can try to ask upstream to implement the feature you are suggesting. And, of course, patches are welcome.

Intention was to reassign to util-linux maintainer.

This is a design problem of FAT: It stores times in local time.

It means that something like "tz=LOCAL" have an unexpected side effect in countries with daylight saving time is applied: time stamp of all files on the card is changed twice a year.

It is because kernel does not implement DST, and the local time -> absolute time in UTC is not unique, and some times are invalid and cannot be mapped.

What is better?

Times in UTC, stable but shifted?

Times in local time, volatile, correct for current files and shifted for files before DST change? (By the way, this option is used by Android and it has an unwanted side effects.)

There is a bug 681109 which widely discusses it (well, it was created before time_offset= implementation.)

What can be done:

1) Make a chance to define time_offset for mounting by udev. (easy)

2) Create some magic for mounting with tz=LOCAL in the mount command (ugly hack)

2) Improve implementation of posixovl to implement smart DST-wise time shifting in userspace. (complicated, requires some hacks for DST-clock-move-back times)

(In reply to Geoff Kuenning from comment #5)
> You are correct that -otime_offset=480 is nonintuitive.  It is also,
> as far as I can tell, utterly undocumented (it's not in any
> mount-related man page, and there is no man page for mount.vfat).
  Yes, the documentation is lacking.
 
> It's also trivially obvious that if mount can implement -otime_offset,
> it can equally well implement -tz=LOCAL or -tz=Europe/Berlin or
> whatever else the user wants.  All it has to do is look up the zone
> and insert whatever offset is approprite.  (Like -otime_offset, this
> approach doesn't deal well with mounts that last across DST changes,
> but that's a small price to pay for getting correct interoperability
> with other systems.)
  Well, the trouble is that mount(8) knows nothing about -o time_offset=X (it just passes it to the kernel as an opaque string which kernel interprets). So you could parse mount options in mount.vfat (which you first have to create because currently util-linux doesn't have a vfat specific mount command) and if you see tz=LOCAL, you could rewrite that to time_offset=X. But it's not a change you write in 5 minutes or even one hour - I had a look at it back when I implemented time_offset= kernel parameter in VFAT, postponed that and never got to it again. But it would be a nice project for someone interested in util-linux hacking.

Jan: ugh.  Putting it in the kernel was a bad idea in the first place, but at least now I understand why it's hard to fix.

Stanislav: this argument boils down to "it breaks in a minor fashion twice a year, so it's better to break in a major fashion all the time."  And of course the degree of breakage varies; if you live in CET then it's only a 1-hour error to mount with UTC, but if you live in California or (worse) New Zealand then it's substantial.  And there are clear interoperability problems with other systems; this is a case where standing up and shouting "I'm right and everybody else is wrong" is not the wisest choice.

In any case, my original point still stands: it's never a good idea to provide option X without giving people the choice of turning X off.  In this case, X and !X used to be available, and now only X is there--despite documentation that clearly states that X is only available when selected.

...which gets back to the "documentation is lacking" point, which in turn gets to the fact that there are too many people who think it's OK to change code without documenting it.  Not that I blame you guys for what is a general attitude among clueless newbie programmers.  Aargh.

Geoff Kuenning: Well, it depends on angle of view.

rsync copying the whole large FAT volume twice a year is an issue as well.

And even if you mount the volume with local time, files half year old are one hour off.


Well, I do at home even more complicated work:

I want to import images from camera with local time zone (to have correct time stamps), but mount generic file systems in UTC (to prevent the mentioned rsync issue).

So the volumes where you sync/copy files by file name: can use local time.

But volumes where you sync/copy by time stamp: must use UTC.

Far the best would be an userspace DST aware FAT driver, or smart time shifting FUSE on top of kernel FAT driver.

(In reply to Geoff Kuenning from comment #10)
> Jan: ugh.  Putting it in the kernel was a bad idea in the first place, but
> at least now I understand why it's hard to fix.
  Well, IMO handling of 'tz=utc' in kernel was a bad idea in the first place. But that's a mistake which has happened long time ago and there's no way we can change that now. Addition of 'time_offset=X' was just a way to give userspace enough control so that it can shift timestamps as necessary (modulo DST issues).
 
> In any case, my original point still stands: it's never a good idea to
> provide option X without giving people the choice of turning X off.  In this
> case, X and !X used to be available, and now only X is there--despite
> documentation that clearly states that X is only available when selected.
  Well, 'time_offset=X' is a way to override 'tz=utc' to something else. I agree there's no way to make kernel use sys_tz variable which may be somewhat annoying when systemd just started mounting all your FAT filesystems with tz=utc.

> ...which gets back to the "documentation is lacking" point, which in turn
> gets to the fact that there are too many people who think it's OK to change
> code without documenting it.  Not that I blame you guys for what is a
> general attitude among clueless newbie programmers.  Aargh.
  Actually, 'time_offset' mount option is documented in Documentation/filesystems/vfat.txt in the Linux kernel. I agree copying the description to mount.8 manpage so that it's easier to find is necessary. I'll send a patch to util-linux maintainer.

(In reply to Jan Kara from comment #12)
> > In any case, my original point still stands: it's never a good idea to
> > provide option X without giving people the choice of turning X off.  In this
> > case, X and !X used to be available, and now only X is there--despite
> > documentation that clearly states that X is only available when selected.
>   Well, 'time_offset=X' is a way to override 'tz=utc' to something else. I
> agree there's no way to make kernel use sys_tz variable which may be
> somewhat annoying when systemd just started mounting all your FAT
> filesystems with tz=utc.

To be precise, systemd didn't change the way of mount itself.  It changed the setup of kernel sys_tz: now it's set to UTC.

Jan,

>  Actually, 'time_offset' mount option is documented in
> Documentation/filesystems/vfat.txt in the Linux kernel. I agree copying the
> description to mount.8 manpage so that it's easier to find is necessary. I'll
> send a patch to util-linux maintainer.

Thanks.  I think that's the best solution to an ugly problem.  I'd suggest that the patch make it explicit that this is a way to invert the tz=UTC option.

Looking at the kernel documentation (which is a weird place to put that kind of thing), I see that there are tons of other VFAT mount options that have been omitted from the man pages.  So I'd ask that along with your patch, you ask the util-linux maintainer (or somebody!) to write a proper mount.vfat man page that documents *all* the options, rather than just a few.  I don't consider it your responsibility to write that; you're already going above and beyond by offering to write a patch to mount.8.

Actually there weren't that many options missing (a catch is that the options are split between FAT and VFAT mount options section). But there were other three or four mount options missing so I've added those as well.

I could certainly add something to posixovl if that helps you. It seems doable.

Jan Engelhard: The reverse mapping has a problem: It depends on timezone description and for DST time zones it is not unique for one hour in year.


I have been looking at posixov ant testing the Factory version of posixovl, and I can imagine more improvements:

- usability for non root users: even if mounting both VFAT and posixovl with proper uid/gid and do chown on root node, and I see correct UID, I get EACCES when trying to use as non-root user.

- Possibility to store high resolution time stamps (interesting together with UTC/localtime issue)

- Fix case insensitivity and problem with shortname!=mixed.

- Fix possible name clash (case clash, posixovl file clash and filename length overflow)

- support for ACL and XATTR.

- Integration with udisks (mkfs will create root entry, and udisks will automatically mount the overlay), so it could be seamlessly usable by non advanced users.

(In reply to Jan Kara from comment #9)
> Well, the trouble is that mount(8) knows nothing about -o time_offset=X
> (it just passes it to the kernel as an opaque string which kernel
> interprets). So you could parse mount options in mount.vfat (which you first
> have to create because currently util-linux doesn't have a vfat specific
> mount command) and if you see tz=LOCAL, you could rewrite that to
> time_offset=X. But it's not a change you write in 5 minutes or even one hour
> - I had a look at it back when I implemented time_offset= kernel parameter
> in VFAT, postponed that and never got to it again. But it would be a nice
> project for someone interested in util-linux hacking.

Hope that helps:
https://bbs.archlinux.org/viewtopic.php?pid=1465171#p1465171
I put that mount.vfat to /sbin. It sets time_offset using date command.
With this mount.vfat I get correct timestamps when accessing an sdcard from my camera.
(bios clock is set to utc, timezone is Europe/Berlin, camera is configured to local time)

Reimar Imhof: Nice idea.

It is useful for importing images from camera or phone, but harmful for rsync.

The script could be enhanced:

- Add configurable sysconfig support.
- The configuration will contain list of UUIDs with exceptions.

Idea:

/etc/sysconfig/mount:

VFAT_MOUNT_TZ="UTC"

VFAT_MOUNT_TZ_EXCEPTIONS_1="F009-64A5 A49F-58C7"

VFAT_MOUNT_TZ_EXCEPTIONS_1_TZ="CURRENT-LOCAL"

VFAT_MOUNT_TZ_EXCEPTIONS_2="4DF1-E022"

VFAT_MOUNT_TZ_EXCEPTIONS_2_TZ="-1"


Well, even better would be implementing this into udev/udisks instead of stealing of mount.vfat.

Mmmm...depends on how you use rsync.  I originally encountered the issue when I was using rsync to update a bunch of thumb drives where I wanted to local time to show up as the timestamp.

But I like Stanislav's enhancement suggestions.

I just created two Hack Week proposals:

Improve posixovl to support fully featured POSIX file system on top of any limited file system (e. g. vfat)
https://hackweek.suse.com/12/projects/806

mount option helper for VFAT and other file systems
https://hackweek.suse.com/12/projects/810

Looking at the automatic desktop mounting a bit deeper, a work-around like hacked mount.vfat looks odd to me:
- It would be intended to work-around missing feature of desktop by hacking nearly the lowest level of the chain.
- And it may not work on desktop, because udisks2 may overwrite options by its own defaults.

How the desktop mounting works:

1. kernel sends a notification
2. udev processes the notification
3. It is passed to udisks2
4. VFS layer of the desktop GUI gets the notification (e. g. gvfs)
5. It passes it to the desktop application (e. g. nautilus or thunar)
6. Desktop application decides to mount using VFS layer
7. VFS layer calls udisks2 mount method
8. udisks2 mount helper processes the request and calls mount
9. mount performs some checks and calls mount syscall.
10. kernel mounts the volume


It's interesting that udisks2 itself supports mount options. See "udisksctl mount --help".

But desktop layers above don't make them accessible.

Even if they will, they don't implement any way to set mount options volume or device specific.

=> It means that udisks2 always used defaults. Defaults are hardcoded:
udisks-2.1.5/src/udiskslinuxfilesystem.c: static const gchar *{fs}_defaults

Here is a proof of concept of udisks mount options configuration (result from the passed Hack Week):

Sources:
https://build.opensuse.org/package/show/home:sbrabec:branches:udisks2-mount-conf/udisks2
Binaries:
http://download.opensuse.org/repositories/home:/sbrabec:/branches:/udisks2-mount-conf/
(Installation of udisks2 sub-package is sufficient for experimenting.)


The patch has a fundamental problem, that will require more changes:

- Mount daemon is ran as root with root privileges, but we would like to get mount configuration file and time zone from the calling process (using caller's variable). It would require API changes. (For now, it looks up to /etc/xdg/udisks/udisks2-mount.conf and ~root/.config/udisks/udisks2-mount.conf (It can change.)

- No support for Unknown medium mount agent yet. Maybe it would be nice to write only a simple sample of the agent, and let desktop environments to implement by its own.

- TZ support is not yet included, but it will mean a trivial patch extending allowed options plus a bit more complicated (but still simple) computation of the local time offset.

How it works?

It accepts mount configuration file /etc/xdg/udisks/udisks2-mount.conf in a format:

[name of the rule]
Options=list;of;needed;options;
{Condition}=list;of;potential;matches;

If all lines of the rule match, then mount options are applied.

Currently are implemented only: Type, UUID, Label, Usage, Version (case matters). More from the udisksctl dump can be easily implemented. Especially device ID (e. g. everything in my camera) and removable flag (i. e. every removable device).

The configuration file matches the standard GKeyFile format.

Example that already works:

/etc/xdg/udisks/udisks2-mount.conf:

[Set shortname to upper]
Type=vfat
UUID=CB6C-D3C8
Options=shortname=lower;

I did a step forward. Now it is really usable.

Now it accepts a configuration options in /etc/udisks2-mount.conf and ~/.config/udisks2-mount.conf (files were moved).

Time shifting can be configured.

Example of ~/.config/udisks2-mount.conf:

[my camera]
Type=vfat
UUID=CB6C-D3C8
Options=shortname=lower;time_offset=-120;


API now recognizes new error:
UDISKS_ERROR_SYNTAX_ERROR = org.freedesktop.UDisks2.Error.SyntaxError


To Do / Problems:

- Documentation needs update.

- Add matching keys from drive description (physical location of port, removable flag, medium format flag etc.).

- No GUI editor for this file, ideally catching udisks mountable device events.

- Bad options intentionally cause fatal error. But several GUIs ignore it.

However error is issued including the description:
udisksctl mount --block-device /dev/sdc1 --options time_offset=60
Error mounting /dev/sdc1: GDBus.Error:org.freedesktop.UDisks2.Error.OptionNotPermitted: Malformed mount option `shortname=lower,time_offset=-120' (separate udisks2-mount.conf options by ";")


I was thinking about ways to pass environment from the client to the daemon. It is theoretically possible without any client API change: DBus supports GetConnectionUnixProcessID service. With the PID, I can access read environment. But it looks like an ugly approach.

Alternative approach:

- Do not base config location on XDG environment, use fixed location instead. It's easy to do, but it could make problems e. g. with private AFS mount not accessible for root. (If it will be an issue, config file would have to be parsed by client.)

- Required environment parts (e. g. timezone for FAT, locale for ntfs or smarter codepage selection) needs to be addded to the client, which will pass them to the daemon as a special mount conditions. E. g.: "x-udisks-tz=".

This alternative approach requires code addition to all clients.

Patch sent to the upstream as RFC: http://lists.freedesktop.org/archives/devkit-devel/2015-April/001668.html

(In reply to Takashi Iwai from comment #4)
> About why kernel TZ setup was disabled by systemd, read the following:
>   https://www.libreoffice.org/bugzilla/show_bug.cgi?id=81538

This bug does not exist (any longer?). Could you update the link, or put a bug title to search for? Thanks.

(In reply to Jan Kara from comment #12)
> Actually, 'time_offset' mount option is documented in
> Documentation/filesystems/vfat.txt in the Linux kernel.

So I need to install kernel sources to find out about some obscure option working around a problem that didn't exist before?
Either man mount or mount --help must be sufficient.

I've just wasted hours on this problem, wondering why rsync has become useless for syncing android devices. In the past, time stamps where out by DST, on oS 13.2 by 13h.

It's quite ridiculous kernel time zone settings, stable for 20+ years, get changed without means of compensation - unless one counts mount -o time_offset= as such.

Unfortunately, time_offset= doesn't even help because time+date programmers fail at basic maths: given a range of -12 to +12, adding 1, oh shock, one might get 13!! It's not the first time it happened either.

I live in a country that uses a +1h DST offset located in time zone +12h.

mount -o time_offset=780
Unrecognized mount option "time_offset=780" or missing value

721 fails too, 720 is the highest one that is accepted.

Using a value of 720 does not correct the time stamps on a file created 5min ago - they're still 1h out. So useless, basically.

I'm also not entirely sure that time_offset=780 would have the same effect as tz=UTC had in previous oS releases (like 12.3).

That either non-DST or DST stamps are incorrect by the DST offset is probably unavoidable unless DST offset rules are included in filesystems like vfat (mount could load them into the vfat fs module via some API - in theory). Until that happens I'd like the most recent files to be correct.

Allowing users to supply mount options via desktop is great, thanks Stanislav. Previously it was impossible to append tz=UTC for those using digital cameras set to UTC (the only sane option, really).

Until fixes end up on the users' desktop there's a short utility to get the old behaviour back here
(gcc -o set-sys-time-minuteswest set-sys-time-minuteswest.c, call with -1):

http://volker.top.geek.nz/soft/odd/set-sys-time-minuteswest.c

The bug still half exists.

It is now possible to specify TZ in kernel.

But desktop user space tools are not capable to use this feature, at least not without hacking and root privileges.


Comment 27: Valid point. util-linux mount man page needs to be updated.


Comment 28: Jan, offset range needs a kernel fix.


Yes, Android has the same problem.


To the conversion of time stamps: It is even worse:

- VFAT does not specify time zone at all.

- Older version of Windows OSes always wrote time in the local time zone.

- Local time can be mapped to UTC only in 99.99% cases. The rest 0.01% has no unique mapping (the hour when DST moves to non-DST has undefined mapping to UTC).

- DST handling in an ugly and large block of code, which will likely never be in kernel. Imagine how many kernel problems were triggered by leap second.

=> DST handling will likely never be in kernel. I can imagine the only way to implement it: FUSE on top of VFAT.

(In reply to Volker Kuhlmann from comment #27)
> (In reply to Jan Kara from comment #12)
> > Actually, 'time_offset' mount option is documented in
> > Documentation/filesystems/vfat.txt in the Linux kernel.
> 
> So I need to install kernel sources to find out about some obscure option
> working around a problem that didn't exist before?
> Either man mount or mount --help must be sufficient.

Recent mount.8 manpage has the information about time_offset mount option. It just isn't in 13.2...

(In reply to Volker Kuhlmann from comment #28)
> Unfortunately, time_offset= doesn't even help because time+date programmers
> fail at basic maths: given a range of -12 to +12, adding 1, oh shock, one
> might get 13!! It's not the first time it happened either.

Heh, I didn't think of DST in zone GMT+12 when writing that kernel code... I'll send a fix.

> Using a value of 720 does not correct the time stamps on a file created 5min
> ago - they're still 1h out. So useless, basically.
> 
> I'm also not entirely sure that time_offset=780 would have the same effect
> as tz=UTC had in previous oS releases (like 12.3).

Well, tz=UTC is equivalent to time_offset=0 - i.e., kernel does not apply any correction to the dates stored in the filesystem.

OK, patch submitted.

(In reply to Jan Kara from comment #32)
> OK, patch submitted.

Just repeating here:

If the kernel uses +-24 in places then please stick to +-24. There may 
be a reason for that not everyone knows about. The purpose of the range 
check is to be a SANITY check, not to tell me, the user, how I have to 
operate my system. If I want 3 minutes, I want 3 minutes, and it's not 
the kernel programmer's job to enforce.

Or do you wish to track the legal time zone AND DST offsets in every 
place in the world, make a list, stick that into the kernel, and 
maintain it? I hope not.

A good limit would be 2 less of whatever fits into 8 bit. Or something 
like that. Like +-120.

Thanks for fix, though you owed it I think ;-)

(In reply to Stanislav Brabec from comment #29)
> Yes, Android has the same problem.

I know. Because someone was dumb enough to use this vfat billy brainfart there. Broken by design!

> To the conversion of time stamps: It is even worse:

I know. But before, at least the time stamps on files modified since the last DST change (and reboot) were correct. That is no longer the case, except for those in the zero zone. And in the past the error was the DST offset, now it's the zone offset on top of it. It was broken before, but still much better than now.

(In reply to Jan Kara from comment #31)
> Well, tz=UTC is equivalent to time_offset=0 - i.e., kernel does not apply
> any correction to the dates stored in the filesystem.

OK thanks for clarifying! I think that really needs to be in the man page too. "tz=UTC - shortcut for time_offset=0" would be enough.

(In reply to Volker Kuhlmann from comment #33)
> A good limit would be 2 less of whatever fits into 8 bit. Or something 
> like that. Like +-120.

Why limit to 8 bits? (I mean, yeah, with 8 bits, one can trivially encode -31.45 … +31.45 in 15 minute increments, which fits the current world use, but why stop there?)

Data structures holding zone values have traditionally been 8 bit I think.
But yes, why enforce a limit at all? User error, user problem. It's not that it won't be immediately obvious where the problem was...
Perhaps even better would be to print just a warning "offset seems unusally big" if it exceeds +-24h?

Keeping in mind here that there's no protection for rm -rf / either...

As Ogawa wrote, we want some sane limit on the time offset value so that we don't have to care about overflows and similar stuff. So I agree +-24 hours is a good limit but more than that doesn't look useful to me.

(In reply to Volker Kuhlmann from comment #35)
> (In reply to Jan Kara from comment #31)
> > Well, tz=UTC is equivalent to time_offset=0 - i.e., kernel does not apply
> > any correction to the dates stored in the filesystem.
> 
> OK thanks for clarifying! I think that really needs to be in the man page
> too. "tz=UTC - shortcut for time_offset=0" would be enough.

Current manpage has:

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.

Which I believe explains the situation well.

Volker Kuhlmann comment 34: All ways to use VFAT timestamps are broken:

- tz=UTC: No problems with rsync(*), two time offsets in Windows

- tz={my_zone}: No problems with rsync when used consistently the same zone(*), 1 hour offset in Windows for files with DST

- tz={my_zone_plus_DST}: All time stamps change when DST status changes (and half of them becomes incorrect), causes problems with rsync, but recent files always have time stamp equal to the one in Windows. 0.01% of files has ambivalent time stamp.

(*) VFAT has only 2 seconds time resolution, so even in the best case, --modify-window=2 is safer option.


The best solution that would be a FUSE file system operation on top of VFAT, which will be aware of DST conventions (user space can do it because glibc stores them) and will convert time stamps in a stable way. It will have only the problem with 0.01% of files having ambivalent time stamp.

IMHO it would be a nice project for improving posixovl.

(> Current manpage has:
> tz=UTC

Accurate. And annoyingly unhelpful, because it does NOT explain the relationship with time_offset. Nothing what it says is wrong, it's just not complete.

As user, what I want to know from time_offset:
What happens when set to 0?
What happens when set to +3h?
Does any kind of attempted zone or DST correction still take place?
Its name implies an offset - that doesn't mean that offset isn't on top of all the automation!!

And I'd want to know what happens when neither time_offset nor tz=UTC are used.

All these 3 case together need to explain what happens to timestamps. There is nothing that says tz=UTC and time_offset are not completely independent!

I stand by this - tz=UTC being a shortcut for time_offset=0 needs to be mentioned.
time_offset needs to be properly explained.

BTW there seems to be a common misocnception that DST offset is always 1h. This is most definitely not the case! Some places have 15 or 30 minutes. Gotcha. Yet again.

(In reply to Jan Kara from comment #38)
> So I agree +-24 hours
> is a good limit but more than that doesn't look useful to me.

Well it does to me, as I pointed out by email. Past abysmal failure at primary school maths resulted in time stamps being moved forward by around 2-3 days. Mounting with an extra big offset could readjust that. But there are other ways not involving that vfat P.o.S. and are therefore probably better.

(In reply to Stanislav Brabec from comment #40)

You forgot to add:
- tz={my_zone}: 0.01% of files have ambivalent time stamp.

The same applies to all application software showing or accepting time in local time. No convention or even mechanism exists to distinguish the 2 identical hours.

This version of openSUSE changed to end-of-life (EOL [1]) status. As such
it is no longer maintained, which means that it will not receive any
further security or bug fix updates.
As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
openSUSE, or consider the bug still valid, please feel free to reopen this
bug against that version, or open a new ticket.

Thank you for reporting this bug and we are sorry it could not be fixed
during the lifetime of the release.

[1] https://en.opensuse.org/Lifetime