Date:	Thu, 26 Jun 2008 07:23:47 -0600
From:	Joe Peterson <joe@...rush.com>
To:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
CC:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] UTC timestamp option for FAT filesystems

OGAWA Hirofumi wrote:
>> So FAT filesystem timestamps make sense in one of two modes for a given
>> volume: local time or UTC.  The former handles volumes used under
>> Windows well, and the latter would be extremely useful for other devices
>> which use FAT filesystems but need to have a more sensible "real" time
>> format (like, as I pointed out, digital cameras).
> 
> Um, so how does the camera show the timestamp of file? UTC seems to be
> hack for changing FAT for Linux. Arbitrary value is more useful and
> correct option, I think.

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.

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).

> 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)

This is one case in which Linux's method of FAT local time correction
breaks down, and the real root of the problem is that FAT is not using
UTC.  If, in Linux, the same FAT partition were looked at 6 months
later, the two times would still differ by one hour, but they would both
also be shifted by one hour due to the kernel's different DST correction
(i.e. the "other one" would now read "12:00".

As I mentioned, local time is not a realistic way to handle time anyway,
but the paradigm has existed in DOS/Windows FAT throughout its history
(note that NTFS, on the other hand, behaves more like a real fs).

So, if one were to, instead of UTC, use an arbitrary "fixed" offset when
mounting a FAT partition, the same issue would occur (Linux and Windows
would not agree always).

						-Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists