public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joe Peterson <joe@skyrush.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] UTC timestamp option for FAT filesystems
Date: Wed, 25 Jun 2008 20:44:22 -0600	[thread overview]
Message-ID: <48630286.2050006@skyrush.com> (raw)
In-Reply-To: <4862DB28.3050001@skyrush.com>

Joe Peterson wrote:
>> Also even if it worked it seems very limited. If you do that why not
>> have an option to set an arbitary time zone offset?
> 
> Yes, I thought about also providing an option that lets the user specify the
> offset at mount - this may be useful for other scenarios (like moving Windows
> disks between time zones), but the UTC option, itself, is very useful in that it
> let's one use UTC on FAT devices, which is the least problematic way to do
> things (e.g. for digital cameras, etc.).

After thinking about this some more, I actually do not see much point in
allowing an arbitrary offset on FAT.  Only two modes make sense: local
time (current default) and UTC (new proposed option).  Here's the
reason: in "local time" mode (the default in Linux and Windows), a FAT
filesystem records just that to the disk: local time.  For example, on
Windows, it doesn't matter which time zone is in use; a file written at
12:00 will still show a time of 12:00 even if the time zone is changed
on the system.  If a user with a Windows laptop travels around, changing
the time zone, files saved at noon in one time zone will appear to have
the same time when in another.  This does not make sense in a "real
time" sense (it would be possible, for example, to have a file written
later but with an earlier timestamp if the user crosses a time zone
boundary to the west (and sets the time zone) just before saving the
second file).  Such a typical traveling Windows user will have files
saved in many different time zones, so there would be no meaning to
setting an arbitrary time zone offset when mounting such a volume.  The
files on the volume would just have to considered stamped in "local
time", wherever the user happened to be.

Linux's implementation of FAT "local time" mode does this as well.  It
simply adds to a timestamp exactly what the userland level will subtract
when displaying the time, making that timestamp appear as it is
numerically on the disk, in local time.

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

						-Joe

  reply	other threads:[~2008-06-26  2:44 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-25  5:24 [PATCH] UTC timestamp option for FAT filesystems Joe Peterson
2008-06-25 22:33 ` Andi Kleen
2008-06-25 23:56   ` Joe Peterson
2008-06-26  2:44     ` Joe Peterson [this message]
2008-06-26  7:32       ` OGAWA Hirofumi
2008-06-26 13:23         ` Joe Peterson
2008-06-26 14:37           ` OGAWA Hirofumi
2008-06-26 15:45             ` Joe Peterson
2008-06-26 16:26               ` OGAWA Hirofumi
2008-06-26 17:06                 ` Joe Peterson
2008-06-28 22:24                   ` James Cloos
2008-06-29  5:03                     ` Joe Peterson
2008-06-29  8:20                       ` Bernd Eckenfels
2008-06-26 17:21                 ` Joe Peterson
2008-06-26 18:15                   ` OGAWA Hirofumi
2008-06-27  5:12                   ` Joe Peterson
2008-07-01 23:25                     ` Andrew Morton
2008-07-02  4:43                       ` Joe Peterson
2008-07-01 23:27                     ` Andrew Morton
2008-07-02 14:47                       ` Joe Peterson
2008-06-26 16:01             ` Joe Peterson
2008-06-26 17:08               ` OGAWA Hirofumi
  -- strict thread matches above, loose matches on Subject: below --
2008-06-25 13:31 barry bouwsma
2008-06-25 14:42 ` Joe Peterson
2008-06-25 19:35   ` barry bouwsma
2008-06-26  4:24     ` Joe Peterson
2008-06-26 19:07       ` barry bouwsma

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48630286.2050006@skyrush.com \
    --to=joe@skyrush.com \
    --cc=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox