Re: [PATCH] FAT timezones

Edgar Toernig (froese@gmx.de)
Sun, 21 Nov 1999 06:44:44 +0100


Hi,

> Here's the mount option for msdos/vfat: "tzoff=N" where N == minutes
> west of UTC. Being very much a kernel-hacking newbie, I haven't
> figured out how to get "-o remount" yet. (This patch, as simple as it
> is, took me a lot longer than you'd think....)
>
> The idea is that mount(8) could be enhanced to detect a FAT mount,
> parse your "tzoff=PST8PDT" parameter, substitute number of minutes in
> and pass it on. Also, mount(8) could use a default "tzoff=" parameter
> with the system's or user's current time zone. (I haven't touched
> util-linux yet, but it's on my todo list.) Furthermore, when DST comes
> and goes, a cron job could remount all the FAT partitions to offset
> them by an hour. All the policy in user space....
>
> Alexander, what do you think of this (other than the current lack of
> "remount" support)? In my opinion, since FAT does not store absolute
> dates, the user who mounts the FS should get to decide on the time zone
> for it.
>
> [patch snipped]

What is it good for? settimeofday is the kernel function to set the
time zone offset. You may say that there's only one timezone for the
complete system but that's the same for MSDOS. Having two disk with
dates from two different timezones will not work under MSDOS either.
And it still does not handle two processes with different timezones.
So why add some hacks to handle something that's broken by design?
You cannot really fix it in any reasonable sane manner.

The only shortcut of the current implementation is the missing/broken
handling of daylight saving time. And that is not fixed by your patch.
Just setting a new GMT offset at DST change time is not enough.
The filesystem has to convert every date it finds on the fs to zulu
time and for that it does not have to know if DST is currently in effect
but if DST was in effect at the time of the date stamp.

Ciao, ET.

PS: I'm off now from the discussion about FAT timezone handling. I was
just afraid that this patch may get into the kernel. There are already
enough strange things going into the kernel *g*

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