Re: [TCLCORE] TIP #173, time zones and redundancy

[<ke...@cr...>]

xt...@de... said:
> I don't have a vote on TIPs, but speaking as the official Tcl/Tk
> maintainer for one of the most popular Linux distributions (Debian),
> I'd be sorely tempted to rip out any tcl-specific code in this area
> and replace it with simpler and more consistent (with the rest of the
> system) C code.

Uhm, right.  Sort of.  Everything you say is true.  With some
caveats upon which the whole idea may stand or fall.

(1) The Olson codes, which include the 'gmtime' and 'localtime'
    variants that use /usr/share/zoneinfo, still have the Y2038 bug.
    It would be nice if Tcl could fix that before C does. We
    haven't very many more years before it really starts hitting
    the banking industry; there are a lot of 30-year bonds and
    30-year mortgages out there.

(2) Windows does NOT have any analogue to /usr/share/zoneinfo, and
    in fact cannot deal gracefully with changes to the rules for
    Daylight Saving Time.  It gets DST wrong, for instance, for all
    US times prior to 1985.  Its standard C library is also
    fraught with bugs, which is why Tcl doesn't even use the
    system's 'strftime' call on Windows.

(3) If we depend on the C library functions 'localtime' and 'gmtime',
    then we have access to only two time zones: UTC plus some
    "local time zone" that's determined by tzset.  One thing that
    started me down this road was that I have a server application that
    wants to format times in the client's time zone.  Changing the
    time zone in the C library gets very tricky; you have to change
    the TZ environment variable, call tzset, call localtime, and
    then put TZ back.  In a multithreaded process, you also have to
    arrange mutual exclusion around all of this - and often around
    all accesses to the environment.  While possible, this gets
    very ugly very fast - and leads to some fragile code.  I really
    don't want to go there if I can possibly avoid it.  One
    of the beauties of Tcl is how seldom I have to worry about thread
    safety, even in a multithreaded process.

(4) The maintenance of Tcl's time zone definition files is easier
    than you might imagine, owing to the fact that they're built from
    the same source distribution as /usr/lib/zoneinfo.  It's really
    just a matter of downloading a fresh set of tzdata from
    elsie.nci.nih.gov and doing 'make tzdata'.  Also, the
    plan would be to package the files in a zip filesystem, which packs
    them down to 370 kbytes or so.  It's still fat, I know, but
    what can you do?

(5) If even 370kb is unacceptable, I have already written code that
    reads the /usr/share/zoneinfo files directly, with the caveat that
    the [clock] command will get DST wrong after Y2038 (it'll still
    work otherwise).  I'm willing to do a special case for Linux
    [Linux specifically] so that a distribution that omits the Tcl
    time zone data can still use the system data.  The code needs
    to be Linux-specific, because even the majority of Unix systems
    that do use the Olson codes have all sorts of different places
    for keeping the data.  The paths have differed even on different
    *releases* of Solaris, causing no end of fun for statically
    linked binaries.

Can we compromise here?

--
73 de ke9tv/2, Kevin KENNY   GE Corporate Research & Development
ke...@cr...           P. O. Box 8, Bldg. K-1, Rm. 5B36A
                             Schenectady, New York 12301-0008 USA