Subject: [Tzdist] #11 Proposal to not define any JSON format

From: Tobias Conradi <[email-masked]>
Date: Tue, 26 Aug 2014 18:29:10 +0200

Instead of doing any definitions of JSON output and kind of re-invent
the wheel, I propose to use the iCalendar format.

The tzdist charter demands this anyway:
---------------
The working group will work under the following parameters:

- The time zone data distribution protocol will initially be targeted at
iCalendar-based clients
-----------------

A JSON representation of the iCalender format exists, and if this is
lossless then a reference to that representation is sufficient.

If there is no trust in that, then xCal might be considered, which
could be tested with a DTD and one just names a standard lossless
transformation from XML to JSON.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Lester Caine <[email-masked]>
Date: Tue, 26 Aug 2014 17:51:38 +0100

> lossless then a reference to that representation is sufficient.

This does depend on your definition of 'lossless'. iCalendar VTIMEZONE
changes the data provided by tz in a manor that prevents the original
data from being recreated. Some aspects of the tz data such as the
common rule sets are lost in this process. Therefore data has been lost.
While this may not be a problem in serving up client data, it may be if
trying to identify which tzid's have been updated following a change in
the common rule on tz.

Other data is tagged as 'optional' in iCalendar so in theory can be
dropped, but in order to make a reliable distribution process these
fields need to be flagged as required by the tzdist usage of them.

I'm not to bothered if the missing json version of the get function is
not part of the first version. I think that it will be developed as part
of the distribution process feeding the root servers in order to
maintain transparency with the core data. We do not need to 'get' every
copy of a tz if there is only a change to the base rule, but that is not
possible with the VTIMEZONE conversions.

I am more concerned about just how updates will propagate through the
system, and this process now seems to be spread across several tickets
so I'll attempt to outline where I think I've now 66ot to in a separate
post.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 26 Aug 2014 13:02:13 -0400

Hi Lester,

> trying to identify which tzid's have been updated following a change in

So my thought on how data gets from a primary to a secondary server is that 
the secondary will check the primary to see what formats (MIME types) are 
supported, use action=list to find all the tzids, then action=get&format=X 
for each format. i.e., the secondary is "replicating" the actual data 
returned by the primaries action=get, as opposed to deriving a set of time 
zone data from the primary's underlying source.

Note that my server can act as a secondary as well as a primary and that 
only sucks down the text/calendar format and derives 
application/calendar+json from that - that is an optimization that it can 
make on the basis that iCalendar/jCal conversion is lossless and that the 
primary is not likely to include data in iCalendar that is not in jCal. If 
the primary also had a totally different format (e.g., 
application/timezone+zoneinfo) then my secondary would have to pull that 
down separately.

Given that, there is no need to have a standard "lossless" definition of 
time zone data at least as far as primary->secondary data replication is 
concerned.

-- 
Cyrus Daboo

---

From: Tobias Conradi <[email-masked]>
Date: Tue, 26 Aug 2014 19:03:46 +0200

On Tue, Aug 26, 2014 at 6:51 PM, Lester Caine <[email-masked]> wrote:
> This does depend on your definition of 'lossless'.
Mine means, that the iCalendar data can be re-created from the JSON
representation.

> iCalendar VTIMEZONE
> data from being recreated.
If there is a JSON representation of IANA tz data then, I would assume
that could also be represented in the iCalendar format.

Maybe you can give an example in JSON of which you think it cannot be
represented in iCalendar, if there is such.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com