On 15 July 2015 at 08:45, Steffen Nurpmeso <sdaoden@yandex.com> wrote:
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.
Not that this should become a tzdist discussion, but it is my understanding that tzdist has left the distribution of compiled binaries for zones to future work. In particular, this would require writing up a spec describing the binaries compiled by zic. Certainly not insurmountable, but also not a priority at this time. http://www.ietf.org/mail-archive/web/tzdist/current/msg01207.html http://www.ietf.org/mail-archive/web/tzdist/current/msg01218.html §4.1.2 of the latest draft (draft-ietf-tzdist-service-09) says <https://tools.ietf.org/html/draft-ietf-tzdist-service-09#section-4.1.2> that "Clients use the HTTP Accept header field (see Section 5.3.2 of [RFC7231]) to indicate their preference for the returned data format. Servers indicate the available formats that they support via the 'capabilities' action response (Section 5.1)." So, as I understand it, there's definitely room for tzdist implementations to support this even without the file format being formalized. -- Tim Parenti