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.