Re: [PATCH] UTC timestamp option for FAT filesystems

Joe Peterson <joe@xxxxxxxxxxx> writes:

Since the camera does not have a concept of time zone, the camera's
clock, itself, would show UTC. You are correct that one could, instead,
choose an arbitrary time offset when setting the camera's clock, and if
an option existed in Linux to always use this fixed offset on mount, the
Linux timestamp could be correct in this case as well.

It means the timestamp of FAT on the camera is just wrong.

However, there are some issues I see with choosing to do this:

1) It is more confusing than using UTC (the user, in essence, is
defining a new absolute reference time similar to UTC but not UTC (and
that matches his local time, at least for 1/2 the year).

2) If the user moves, either the camera and mount offset could be left
at the "wrong" setting that would now be less meaningful than UTC, or
the user could change both.

3) When the daylight saving time switch happens, the camera's time will
now be wrong, even though the Linux time will still be OK - they will
differ by 1 hour unless corrected. If the camera could (and did) adjust
for DST automatically, then this would give a bad Linux time and
potentially go unnoticed until the fixed offset were corrected (note
that my camera does not ever auto-adjust; I'm not sure if any can).

So in cases 2 and 3, the user would end up needing to change the offset,
perhaps twice a year. This is one thing I am trying to avoid by just
using UTC. Using UTC as the "fixed offset" is the only one that makes
sense in that if one is to choose some arbitrary "universal time", it
might as well be UTC (and there are no DST issues with UTC).

Of course, UTC is right design for on disk format. But, this is FAT, the
writing UTC means you modified the design of FAT. It is not a correct
option, it is just a hack like I said, right?

However, I can accept that hack for many broken devices on realworld,
but, the modifying design is not right option. Do you see what I want
to say?

It will be specified the timezone of FAT on one disk. So, the timestamp
is right for specified timezone on Windows always, on Linux should be
always right...

No?

Not really. Here's an example:

1) Create a folder on FAT in Windows in winter at local 12:00
2) Create a folder on FAT in Windows in summer at local 12:00
3) Notice that in Windows, they both will read "12:00"
4) Mount the volume under Linux with the default "local time" behavior,
and you will notice the times are off by one hour (because Linux
adjusts both by the same offset in the kernel, but userland
correctly adjusts them differently due to different DST status)

Yes. And sys_tz is wrong and needs to fix.

So, if one were to, instead of UTC, use an arbitrary "fixed" offset when
mounting a FAT partition, the same issue would occur

Yes. To store localtime, complex one is needed.
--
OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Strategies for time offsets
    ... There isn't a mechanism for a negative delta time within the quadword storage, though applications are certainly free to stuff a sign bit somewhere. ... The UTC format is often a better choice here, particularly when dealing with the storage of time values. ... And then, in the core of the program, I would simply need to do a LIB$ADD_TIMES and not have to worry about whether the offset is negative or positive. ... Barring cases where this timezone stuff is the bulk of the operation and there's nothing else around consuming more cycles or wallclock time -- I/O tends to be my go-to example here for massive overhead -- I'd tend to look to optimize this math stuff and any associated system call overhead later. ...
    (comp.os.vms)
  • Re: obtaining the time offset from UTC
    ... >> I need to find out the time difference between UTC and local time. ... >> saving and always returns local time zone offset. ... >> When daylight saving is not in effect, then the offset should be +1 hour. ...
    (comp.lang.c)
  • Re: how to make dates without timezones?
    ... the offset from UTC is the local ... clock offset, for the other it is zero regardless of location. ... UTC methods should be faster than local methods, ...
    (comp.lang.java.programmer)
  • Re: Newbie Q: How to program in UTC (time/calendar) ?
    ... I here fight with my intuition :-) ... parameter that defaults to 0 (UTC). ... to the default offset of 0. ... and converting it to the corresponding time for your computer's offset ...
    (comp.lang.ada)
  • Re: Newbie Q: How to program in UTC (time/calendar) ?
    ... I thought "Offset" was reletive to UTC - not relative ... How do I best "input"/enter UTC time (so a reader of the program ... the supplied time from your computer's offset ... and converting it to the corresponding time for your computer's offset ...
    (comp.lang.ada)