Subject: [Tzdist] Observances and start/end

From: Cyrus Daboo <[email-masked]>
Date: Mon, 01 Dec 2014 10:49:03 -0500

Hi,
There has been no further follow-up discussion on the proposal to 
re-organize the URI path for the expand action. At this point I would like 
to propose the following:

1) Change the "expand" action URI from:

{/service-prefix,data-prefix}/observances{/tzid}{?start,end,changedsince}

to:

{/service-prefix,data-prefix}{/tzid}/observances{?start,end,changedsince}

This change basically moves "/observances" to be a child of the actual time 
zone URI. I think this is a reasonable pattern to use since it is possible 
we may "hang" other child URIs of the time zone (e.g., {/tzid}/location 
might return a geospatial representation of the area covered by the time 
zone, or {/tzid}/raw might return the underlying raw publisher data etc).

2) Change the definition of the end query parameter for the "get" action to 
be the exclusive end-point for the selected truncation range (to match the 
definition of end used for the "expand" action). Note, this will mean that 
for systems using a 32-bit unix time_t, the end point may represent an 
integer value outside of the available range. Clients and servers will 
simply have to apply additional logic to handle this case (which they would 
have to do any way if the publisher did in fact support a larger range by 
default). We can have a note (perhaps in the security section) that 
date-time values used in the protocol may exceed supported values and care 
must be taken to handle such overflows.

-- 
Cyrus Daboo

---

From: Stephen Colebourne <[email-masked]>
Date: Mon, 1 Dec 2014 16:02:27 +0000

> zone, or {/tzid}/raw might return the underlying raw publisher data etc).

This is fine by me, providing that the spec is also clarified on the
encoding of tzids, including an example.

Stephen

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 01 Dec 2014 11:18:45 -0500

Hi Stephen,

--On December 1, 2014 at 4:02:27 PM +0000 Stephen Colebourne 
<[email-masked]> wrote:

>> This change basically moves "/observances" to be a child of the actual
>> time zone URI. I think this is a reasonable pattern to use since it is
>> possible we may "hang" other child URIs of the time zone (e.g.,
>> {/tzid}/location might return a geospatial representation of the area
>> covered by the time zone, or {/tzid}/raw might return the underlying raw
>> publisher data etc).
>

I will add some text in Section 4.1 to emphasize that percent-encoding has 
to be done for the various path segment URI template variables. The 
existing examples do show that happening.

-- 
Cyrus Daboo