Message-ID: <877iccxnwi.fsf@devron.myhome.or.jp>
Date:	Thu, 26 Jun 2008 23:37:49 +0900
From:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:	Joe Peterson <joe@...rush.com>
Cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] UTC timestamp option for FAT filesystems

Joe Peterson <joe@...rush.com> 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@...l.parknet.co.jp>
--
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