[uClibc] TZ environment values for glibc timezones

[Mike Primm]

Yep - based on what I've read and found in the code itself, there's 
support for the extended TZ syntax, that looks something like:

/stdoffset/*[*/dst/*[*/offset/*][*,/start/*[*//time/*]*,/end/*[*//time/*]]]
*

where the "start" and "end" stuff is some interesting encoding for 
sayiing "1st Sunday in April" or whatever, as appropriate - here's an 
example for Newfoundland:

TZ=NST3:30NDT1:30

Or, the "long form" for Eastern Standard Time (the extra stuff is 
optional, as US timezone rules are assumed if DST is provided at all):

TZ=EST+5EDT,M4.1.0/2,M10.5.0/2

So, anyway, making up a bunch of these (about 160, at minimum) is pretty 
awful (since everything outside the US pretty much uses different DST 
rules).  I'm hoping someone already did this, but I'll be sure to submit 
back anything I write up if I wind up having to do it myself (probably a 
utility to process the raw TZ rules into something to generate TZ 
environment values).  Just wanted to be sure noone else had already done 
it before "reinventing it".  Even so, this sort of solution is only good 
for folks that need to deal with the "present" time or recent 
past/future - DST rules often change from year to year, so the rules for 
a time in 2005 aren't necessarily the same rules as for 2000 (i.e. 
Mexico had different rules for 2000, 2001 and 2002-present).  It'll work 
for my product (which pretty much lives in the present and recent past, 
from a time point of view), but other folks may need a more dramatic 
change to uClibc itself to cover the more general case (the TZ syntax 
doesn't allow for year-specific rules, so all times are interpreted as 
using the same rules).

--Mike Primm
   NetBotz, Inc.

Ralph Siemsen wrote:

> Erik Andersen wrote:
> > To my knowledge nobody has done this.  Contributions of such a
> > tool and/or data set would be appreciated.
>
> Its actually much more involved than this.  There is not just the time
> offset with/without Daylight time, but also the dates and times when the
> switch happens.  While most of North america has agreed on these values,
> when you go around the world you find a lot of pockets of difference.
>
> I somehow doubt that this sort of handling is in the current code... but
> I haven't looked so maybe I'm wrong :)
>
> -R
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/uclibc/attachments/20050615/3fd80c0a/attachment.htm