[uClibc] TZ environment values for glibc timezones
mike at netbotz.com
Wed Jun 15 19:27:09 UTC 2005
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:
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:
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):
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).
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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the uClibc