[lkml]   [1998]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: kernel knowledge of localtime
    The Right Thing to do is to have the timezone of a filesystem be
    a mount option. Then you need a simple localtime/GMT translation
    table for the file system and everything can work.

    Now, usually the time zone of the file system is the time zone
    that the machine is sitting in, but network servers might change
    that, and you really would like file timestamps not to suddenly
    warp at a DST change (screwing up your file mirroring, backups
    and who knows what else).

    To steal from the standard user-level Olson time zone facilities, all you
    need is a simple table of (localtime,GMT) pairs describing the first
    moment of each offset. In my home town, that's 232 changes in the
    span of Unix time_t, so we're talking 1856 bytes.

    That could be reduced if necessary, but it's certainly nothing to
    panic about. modprobe could even be hacked (or a wrapper added)
    to extract the relevant data out of the user-land time zone files
    and stuff it into the kernel on demand.

    To translate a time, you look for (binary search) the interval which
    starts on or before the time you're looking to translate and ends after
    it. Then you just add the offset computed by subtracting the two
    interval start times.

    There is always a well-defined local time corresponding to any GMT time.
    The other way around, it gets a little more interesting.

    There are some local times (such as the hour 1998-04-05 02:xx:xx in
    Toronto) that don't exist. It jumped from 01:59:59 EST to 03:00:00 EDT
    between 06:59:59 and 07:00:00 GMT. Fortunately, there is only one
    semi-reasonable thing to do in such a situation, which is to map
    the impossible hour to 07:xx:xx GMT, which will get back-mapped
    to 03:xx:xx. Not too awful.

    There are other local times (such as 1998-10-25 01:xx:xx in Toronto)
    that exist twice, once at 05:xx:xx GMT and once at 06:xx:xx GMT.
    Since the file system doesn't distinguish the two, the choice is pretty
    arbitrary. In the implementation I'm thinking of, it turns out to be
    simplest to translate it as the later of the two hours.

    If you really care about having a 1:1 time code mapping more than
    preserving relative order of timestamps, you could map GMT times
    in the earlier hour to the previously mentioned impossible local time,
    but I think that's better to just mangle he times a little.

    (There is a hack that's possible if you want to get really clever
    involving stretching one hour to fit two, but I'm not sure
    if anyone cares all that much.)

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:46    [W:0.020 / U:13.140 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site