Andi Kleen wrote:
quoted text
> 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?

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

quoted text
> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/