Stephen Colebourne <scolebourne@joda.org> wrote: |On 15 July 2015 at 06:09, Paul Eggert <eggert@cs.ucla.edu> wrote: |> Stephen Colebourne 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. Noda, Joda and JSR-310 all use it, no doubt other do to. It |is very reasonable and useful info. The key point being that we don't |just care about what the offset is, but also how that offset is |calculated. We were using this information as it has been a vivid part of the TZ data one and half a decade ago as a signed save_secs field to be added to signed utf_offsec [1]. The information is still in there; i am not ._.; otherwise an official statement on that data i would appreciate, too. What would be an issue to me is instead that TZDIST doesn't offer a binary representation but only (iCalendar,) JSON and XML, which require parser libraries, whereas with CBOR the IETF standardizes a wonderful, extensible and otherwise future-proof binary format that also has been designed with easy JSON mapping in my mind. And especially the more simple JSON/xy libraries read anything into memory before text parsing starts. Just my one cent. Ciao, [1] http://mm.icann.org/pipermail/tz/2012-June/018002.html --steffen