On Wed, Jul 15, 2015 at 2:06 AM, Stephen Colebourne <scolebourne@joda.org> wrote:
On 15 July 2015 at 06:09, Paul Eggert <eggert@cs.ucla.edu> wrote:
Although it is an issue, the DST-vs-STD offsets are implementation details that are neither exposed by the reference API nor exported to zic's output files. Any values they internally have were not intended to be visible when the tzdata entries were written.
I think what Jon is asking, and I'm confirming, is that this data *should* be considered part of the public data exposed by the tzdb project.
Then I'll confirm Paul's point: subdividing the offset should not be considered for part of a user API. Indeed, if we could change history, we should get rid of tm_isdst too. The only place a UTC offset should be meaningful is when converting an absolute timestamp to/from a civil YMDHMS+O, and that should only happen within the date/time library. Why distinguish between {YMDHMS,stdoff=Xh,dstoff=1h,is_dst=true} and {YMDHMS,stdoff=X+1h,dstoff=0,is_dst=*}? They are the same time. There may be some library with a rich TimeZone concept that exposes much of the information found in the the tz files (and they are welcome to try to extract it), but I would claim that such information fills a much needed gap in a core date/time API.