Subject: [Tzdist] 'get' is optional ...

From: Lester Caine <[email-masked]>
Date: Wed, 24 Sep 2014 08:14:48 +0100

Tobias proposed merging 'expand' with 'get', and it prompted a couple
of thoughts.

One of the scenarios I'm trying to address IS the dumb device problem,
and updating large numbers of clock based devices. In the past many of
these devices have required a trek around each in turn, but networking
allows for much more convenient control. Setting the time is well
established and does not need TLS security, and the next step is simply
accessing the next DST transition if appropriate. While 'list' may be
useful to populate the setting screen, all that is actually required is
an expand call. Ideally it would just return the current offset and the
'next' offset which makes a case for not rounding things to the nearest
year.

I think I'm talking myself into an additional function for 'next', but
certainly a server designed only to augment time setting does not need
to be very heavy at all? Implementing just 'expand' and perhaps 'find'
to give the location TZID may be all that is needed?

>From a systems implementation point of view I can see the time setting
and offset management being the one service within a building management
system ... or on a cruse ship ...

-- 
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: Tobias Conradi <[email-masked]>
Date: Wed, 24 Sep 2014 12:45:57 +0200

On Wed, Sep 24, 2014 at 9:14 AM, Lester Caine <[email-masked]> wrote:
>...

When the tzdist-service document is improved in presentation of the
actions then it will be easier to see what currently is specified.

As with the proposal to replace 'substantive change' with a generic
way of filtering, there might be a more general way for 'next'. E.g.
next one, next two, or only the second.

Get changeovers by changeover number (CON)
- CON=1 #the next changeover
- CON=2 #the changeover following the next changeover
- CON=1-6 #the next six changeovers
- CON=1- #the next and all that come afterwards, maybe by default
limited to a fixed quantity of changeovers

Even if currently no scenario is found where CON=2 is useful, the
syntax gives flexibility. Lester may like to only implement CON=1.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Ken Murchison <[email-masked]>
Date: Wed, 24 Sep 2014 08:22:20 -0400

> to give the location TZID may be all that is needed?

This can be easily done with "expand" by just asking for a range from 
the current time to whatever end point the client is interested in.  For 
instance, asking for just 1 year out.  Or make it 6 months, or 3 months.

https://cyrus-test.andrew.cmu.edu/timezone?action=expand&tzid=America/New_York&start=2014-09-24T13:20:00Z&end=2015-09-24T13:20:00Z

{
   "dtstamp": "2014-09-12T17:09:42Z",
   "tzid": "America/New_York",
   "observances": [
     {
       "name": "EDT",
       "onset": "2014-09-24T13:20:00Z",
       "utc-offset-from": -14400,
       "utc-offset-to": -14400
     },
     {
       "name": "EST",
       "onset": "2014-11-02T06:00:00Z",
       "utc-offset-from": -14400,
       "utc-offset-to": -18000
     },
     {
       "name": "EDT",
       "onset": "2015-03-08T07:00:00Z",
       "utc-offset-from": -18000,
       "utc-offset-to": -14400
     }
   ]
}

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Tobias Conradi <[email-masked]>
Date: Wed, 24 Sep 2014 14:49:51 +0200

On Wed, Sep 24, 2014 at 2:22 PM, Ken Murchison <[email-masked]> wrote:

> This can be easily done with "expand" by just asking for a range from the
> current time to whatever end point the client is interested in.  For

The next change may be 2 years away.

The next change may be at point T but what is insecure is knowledge
about the change T+1.

Queries by time ranges make work for the client more complex. When
'Next' gives definitely no more than 1 result, in a range there could
be more than 1 result.

>       "utc-offset-from": -14400,

This "observance"-element has utc-offset-from=utc-offset-to, that
means no change occurred. So, this is not a
utc-offset-changeover-point.

>       "utc-offset-from": -18000,

The name elements and the values look strange.

1)
http://tools.ietf.org/id/draft-ietf-tzdist-service-01.txt
In section 6.4.1
     "observances": [
       {
         "name": "Standard",

not an acronym but a word with first letter in upper-case.

2)
The name field inside
- actions is the action name
- parameters is the parameter name

So, here, is it the observance name?

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Ken Murchison <[email-masked]>
Date: Wed, 24 Sep 2014 09:09:40 -0400

> 'Next' gives definitely no more than 1 result, in a range there could

In a 1 year range, there normally would only be 2 occurrences, but could 
be as few as 0 and *maybe* as many as 3-4.  The client can simply check 
6 months out.  If it finds an occurrence, it uses it whenever it occurs 
and then does another expand for the next 6 months.  If it finds no 
occurrence, then it checks again in 6 months.

Sure, a 'next' action would yield 0-1 occurrences, but the client still 
needs to check again if/when it observes the next occurrence.

'next' seems like an unnecessary optimization to me , but I won't argue 
strongly against it if WG consensus is to add it to the protocol.

> utc-offset-changeover-point.

This observance tells the client what offset is currently in effect.

Section 6.4:

    Response:  A JSON object containing "dtstamp" and "tzid" members, and
       an "observances" member, seeSection 7.3  <http://tools.ietf.org/html/draft-ietf-tzdist-service-01#section-7.3>.  The server MUST include
       an expanded observance representing the time zone information in
       effect at the start of the period.

> not an acronym but a word with first letter in upper-case.

Examples in RFCs are always informative, not normative.

> So, here, is it the observance name?

Its the name of the observance, and in the case of the underlying 
tzdata, they are named "EDT", and "EST".

---

From: Steve Allen <[email-masked]>
Date: Wed, 24 Sep 2014 06:38:30 -0700

On Wed 2014-09-24T09:09:40 -0400, Ken Murchison hath writ:
> In a 1 year range, there normally would only be 2 occurrences, but
> could be as few as 0 and *maybe* as many as 3-4.  The client can
> simply check 6 months out.  If it finds an occurrence, it uses it
> whenever it occurs and then does another expand for the next 6
> months.  If it finds no occurrence, then it checks again in 6
> months.
>
> Sure, a 'next' action would yield 0-1 occurrences, but the client
> still needs to check again if/when it observes the next occurrence.
>
> 'next' seems like an unnecessary optimization to me , but I won't
> argue strongly against it if WG consensus is to add it to the
> protocol.

The history of the tz database contains several instances where the
"next" occurrence of a change was, effectively, yesterday.  A
foolproof solution for that might be some kind of subscription
mechanism where a client registers interest in changes with some
server.  Both a subscription and "next" are a lot of complexity that
may better be avoided by checking more often or having a "manual
reset" feature on the client device.

--
Steve Allen                 <[email-masked]>                WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165    Lat  +36.99855
1156 High Street            Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

---

From: Rob Seaman <[email-masked]>
Date: Wed, 24 Sep 2014 06:56:15 -0700

On Sep 24, 2014, at 6:38 AM, Steve Allen <[email-masked]> wrote:

>> simply check 6 months out.
>> ...

Just a comment on the word "foolproof" here.  Another thread a couple of weeks ago pointed out the possibility of race conditions (under whatever those circumstances were).  A bit of careful analysis of the applicable use cases now could avoid trouble later.

Rob Seaman
National Optical Astronomy Observatory
Tucson, AZ

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 24 Sep 2014 09:57:06 -0400

Hi Tobias,

> 'Next' gives definitely no more than 1 result, in a range there could

That depends on the client. Nearly all calendaring and scheduling clients 
do time-range queries either of servers (calDAV) or of there own local DB. 
They do that because they typically present fixed time ranges of calendar 
data for users to view (today, this week, this month etc).

So what other class of clients are there that would use this service? I can 
see where a very limited device might want to store a "trigger" to change 
the local time when the next tz observance starts because the amount of 
data needing to be stored would be extremely small.

If we do need that, then I suggest it be an extension of the existing 
expand option (advertised via the capabilities) - we would simply allow a 
"next" parameter to be included (or a "next" value for the "end" parameter) 
and the server would expand from "now" up to the next observance and return 
the data for the observance currently in effect up to and including the 
next observance.

In the absence of any immediate demand for this I would prefer it to be an 
extension rather than part of the base spec, but I could be persuaded 
otherwise if we get such client/device developers to speak up and express 
strong interest.

-- 
Cyrus Daboo

---

From: Tobias Conradi <[email-masked]>
Date: Wed, 24 Sep 2014 18:23:24 +0200

I don't see any indention with ">" in Ken's email, that makes it
harder to separate from the email he answered to.

On Wed, Sep 24, 2014 at 3:09 PM, Ken Murchison <[email-masked]> wrote:
> In a 1 year range, there normally would only be 2 occurrences,
"Normally" seems to indicate this is not necessarily so. So it is unreliable.

I am not even sure that 50% of the world's population see two
occurrences in five years.

> but could be
> as few as 0 and *maybe* as many as 3-4.  The client can simply check 6
> months out.  If it finds an occurrence, it uses it whenever it occurs and
> then does another expand for the next 6 months.  If it finds no occurrence,
> then it checks again in 6 months.
That looks like making the work for the client more complex, as
mentioned in the previous email.

If several queries are used to find a simple answer, then also the
traffic increases.

> needs to check again if/when it observes the next occurrence.
Which is much less. Especially if there is none, there could be an
infinite loop of checking 6-month-ranges.

> This observance tells the client what offset is currently in effect.

Including a misinformation in the onset value.

>       an "observances" member, see Section 7.3.  The server MUST include

What is the norm here?

If the norm is an acronym, then the examples are misinformative?

> Its the name of the observance, and in the case of the underlying tzdata,
> they are named "EDT", and "EST".

I propose that to be added to the glossary section.

Observance name:
"Three letter acronyms, in regular life known as time zone acronyms or
time zone abbreviations."

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Lester Caine <[email-masked]>
Date: Wed, 24 Sep 2014 23:50:58 +0100

> https://cyrus-test.andrew.cmu.edu/timezone?action=expand&tzid=America/New_York&start=2014-09-24T13:20:00Z&end=2015-09-24T13:20:00Z

OK part of the problem was I'd somehow switched back to the previous
version of the draft which still had only years ... deleted that now.

Obviously using the current time for expand fixes the first part of the
jigsaw, and while asking for the next year may be workable, simply
assuming if no transitions are present may not be a safe indication that
this is a TZID without DST changes? It is almost a case that a simple
flag for the presence or absence of DST would simplify the client
operation considerably. No DST then all that is required is a fixed
offset and any other code can be skipped.

I WAS thinking of 'next' as an extension for a control system version of
tzdist, but the discussions on merging get and expand would make 'next'
an alternative simple service option. However keeping a nice light
'expand' just makes perfect sense, but I'm building a case for the
return from a TZID which has a fixed offset using a singe "utc-offset"
in a single "observances" element to get around the problem of not
knowing if we may have a future DST transition. I think this eliminates
the other problem I was trying to fix with 'next'

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 24 Sep 2014 23:54:21 +0100

> data needing to be stored would be extremely small.

Master controller for clocks scattered around a building?

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: [email-masked]     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646