Re: kernel knowledge of localtime (user-level implememntation)

Colin Plumb (colin@nyx.net)
Tue, 24 Nov 1998 21:05:50 -0700 (MST)


Petr Vandrovec wrote:
> a) every network protocol (and every filesystem) which stores timestamps
> in localtime is broken
> b) if you want to do it correctly, you must implement complete DST and
> timezone code from libc into kernel
> c) unfortunately, you must be able to set DST & TZONE per mountpoint, not
> globally per kernel
> b2) or you can declare that filesystem stores date/time in GMT and that
> every client expecting localtime is broken... Unfortunately, in ncpfs
> you have to patch NetWare server because of date for "create" is taken
> from server clock (you can disable DST & TZONE on server :-) ), not from
> client request.

I certainly agree that timesone is a mountpoint option, not a system option.
(Making the time zones loadable modules is hopefully the obvious hack.)

The problem comes that the kernel needs to be able to do bidirectional
conversion, and sometimes it gets tricky.

Consider the following times (cut from zdump -v Europe/London):

Europe/London Sun Mar 29 00:59:59 1998 GMT = Sun Mar 29 00:59:59 1998 GMT isdst=0
Europe/London Sun Mar 29 01:00:00 1998 GMT = Sun Mar 29 02:00:00 1998 BST isdst=1
Europe/London Sun Oct 25 00:59:59 1998 GMT = Sun Oct 25 01:59:59 1998 BST isdst=1
Europe/London Sun Oct 25 01:00:00 1998 GMT = Sun Oct 25 01:00:00 1998 GMT isdst=0

Now, on a file system configured for the Europe/London time zone, it is
uncear what GMT time to translate local times from 1998-10-25 01:00:00
through 1998-10-25 01:59:59, because the host OS doesn't store an isdst flag.

It's even more confusing trying to translate the hour starting at 1998-03-25
01:00:00, because that hour doesn't exist! However 01:00:00 GMT is not
unreasonable.

Forutnately, while conversion in the other direction can produce ambiguous
local times (from 1998-10-25 00:00:00 through 1998-10-25 01:59:59 GMT),
the answer is always well-defined.

I'd rather not put this cruft in the kernel at all, but adding
upcalls to reanslation daemons seems like overkill for simple table
lookup.

Here's the flow I'm thinking of:
- You mount a filesystem with the "TZ=Europe/London" option.
- This provokes a search for the rule in the kernel and a call
to modprobe to load it if missing.
- The hacked modprobe calls out to a utility which finds the
appropriate time zone file, strips out the unnecessary rubbish
(like time zone names), adds any necessary wrapping, and loads
it into the kernel.

Um, actually, given the 4K kernel module granularity and the ~1K size
of most of the files, maybe such stripping is unnecessary.

Then all that's needed is a conversion of the guts of Olson's localtime.c
for the kernel. (Why is everyone looking at me?)

Can anyone see any nasty gotchas that I've missed?

-- 
	-Colin

- 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/