Hi Paul,

Thanks for your response.


> First, perhaps you could explain a little why you want to do this,
> since you lose information when you generate Posix strings from
> Olson-style strings.

Currently JavaStations (i.e. JavaOS) gets its time from a time server.
It then gets a time zone string from a DHCP server in order to calculate
the local time. I want to find a straight forward way to generate the time
zone strings which will be sent to JavaOS from the DHCP server. The string is
limited to 256 characters.

> Second, assuming you want to do this sort of thing, why would you want
> to generate [*]?  It's better to generate the following instead:
> 
> 	PST8PDT7,M4.1.0/2:00:00,M10.5.0/2:00:00		[**]
> 
> since [**] will work in years other than the current year.  [**] isn't
> as good as US/Pacific, but it's better than [*].

Now my ignorance is showing. I am not too familiar with all the varients
of the POSIX strings. If you (or anyone else) could send me the standard
(or a reference to the standard) regarding these strings, that would help out.
Also, what is an "Olsen-style" string?

As you state, this second form *is* better than [*], because handling
multiple years solves the problem of JavaStations booting on the last day
of the year and getting old time zone string info from the DHCP server.

> Here's how to generate [**] without parsing the zoneinfo files.  Run
> GNU Emacs, load-library cal-dst, and invoke (calendar-current-time-zone).
> If TZ is US/Pacific, it should return
> 
> 	(-480 60 "PST" "PDT"
> 	 (calendar-nth-named-day 1 0 4 year)
> 	 (calendar-nth-named-day -1 0 10 year)
> 	 120 120)
> 
> and it's easy to generate [**] from this value.
> 
> If you can't use GNU Emacs in your application, look at cal-dst's
> source code for ideas about how to do it.  GNU Emacs doesn't parse the
> zoneinfo files; it just uses ANSI C localtime and gmtime like a good
> citizen.

This is an interesting suggestion. Although emacs itself is not an option
(because this string is potentially generated by the DHCP server), if emacs
used a good implementation, I don't mind borrowing :-). From looking at the
source, emacs uses binary searches to isolate the transition times within
the year. This seems a little tedious and no better than processing the
timezone file (to me) - but I appreciate the suggestion. I guess I was
hoping that there might be better way to find the transition times than
processing the timezone file or using zdump or doing a binary search.

Thanks again,
Tony

