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 17:56:24 -0600 [thread overview]
Message-ID: <4862DB28.3050001@skyrush.com> (raw)
In-Reply-To: <87od5pqh4o.fsf@basil.nowhere.org>
Andi Kleen wrote:
> The time zone handling seems racy. e.g. consider the case DST
> changes on that day. You convert before the switch over
> and suddenly the time offset is different.
Are you saying that the tz code is racy in general (I saw the following thread
that you responded to as well):
http://marc.info/?l=linux-kernel&m=115954057716441&w=2
Or are you saying that the proposed "utc" option makes things racy?
All the "utc" option does (with this patch) is disable application of the
kernel's "tz_minuteswest" offset, so using it actually should remove races with
a DST switch, right?
> I'm actually not sure someone in user space is even updating the kernel
> idea of the timezone for DST on a switch (generally it was assumed it's some
> obsolete BSD concept and that all real programs only use the
> user space glibc implementation that knows all the rules). So
> DST might not be supported at all.
I am not sure about that either (i.e. whether tz_minuteswest is altered on DST
changes or if it is only changed at boot).
And I think you are right that the kernel's idea of timezone (i.e.
"tz_minuteswest") is basically obsolete ("man gettimeofday" talks about this).
> 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.).
-Joe
next prev parent reply other threads:[~2008-06-25 23:56 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 [this message]
2008-06-26 2:44 ` Joe Peterson
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=4862DB28.3050001@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