Subject: [Tzdist] [tzdist] #33 (service): “substantive” change

From: "tzdist issue tracker" <[email-masked]>
Date: Thu, 23 Oct 2014 15:09:12 -0000

#33: “substantive” change

 Current draft has:

    When listing time zones, a timestamp is returned by the server, and
    that can be used later by clients to determine if any "substantive"
    change has occurred in the time zone data.  Clients can use a
    conditional "list" action (see Section 6.2), supplying a previous
    timestamp value, to limit the results to time zones which have
    changed in a "substantive" manner since that previous timestamp.
    This allows clients to cache the last timestamp and to periodically
    poll the server for possible changes.

    A "substantive" change is one which affects the calculated onsets for
    a time zone.  Changes to properties such as a description are not
    treated as a "substantive" change.

 There has been debate on the list as to what exactly a “substantive”
 change is. We need to clarify this. Or alternatively do away with
 “substantive” and instead require any change, no matter how minor, to
 result in the corresponding tzid being reported as changed.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-tzdist-
  [email-masked]       |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  service      |    Version:
 Severity:  Active WG    |   Keywords:
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/tzdist/trac/ticket/33>
tzdist <http://tools.ietf.org/tzdist/>

---

From: Lester Caine <[email-masked]>
Date: Thu, 23 Oct 2014 16:59:57 +0100

>  result in the corresponding tzid being reported as changed.

A "material" change to the results of using a changed set of data must
be flagged, but anything that simply amends documentation does not need
any action to be made to review the effects of a change. The question
perhaps is if a change such as the recent change to an abbreviation
needs to be flagged? I'm not even sure that sort of change even makes it
through iCalendar conversion anyway?

-- 
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: Thu, 23 Oct 2014 18:07:00 +0200

On Thu, Oct 23, 2014 at 5:59 PM, Lester Caine <[email-masked]> wrote:
> be flagged,
Source for that claim?

See also:
http://www.ietf.org/mail-archive/web/tzdist/current/msg00237.html

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 23 Oct 2014 12:12:21 -0400

Hi Lester,

--On October 23, 2014 at 4:59:57 PM +0100 Lester Caine <[email-masked]> 
wrote:

>>  “substantive” and instead require any change, no matter how minor,
>>  to result in the corresponding tzid being reported as changed.
>

At this point I prefer to leave any decision as to a "material" or 
"substantive" change up to the client for now - to keep the protocol simple 
(as opposed to adding a field level sync option which Tobias has proposed). 
That just means the server has to report any change to a time zone as a 
"changedsince" tzid. If at a later date we decide that field level change 
detection is needed we can implement that as an extension.

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Thu, 23 Oct 2014 17:26:35 +0100

On 23/10/14 17:12, Cyrus Daboo wrote:
> "substantive" change up to the client for now - to keep the protocol
> simple (as opposed to adding a field level sync option which Tobias has
> proposed). That just means the server has to report any change to a time
> zone as a "changedsince" tzid. If at a later date we decide that field
> level change detection is needed we can implement that as an extension.

Actually this is all controlled by the publisher anyway. At a basic
level only start and stop times for a truncated period of time will be
provided anyway and so each time the publisher makes a change it will
affect the client. If the publisher is including additional narrative
data ten it would be for some practical reason and so again any change
needs forwarding.

"Source for that claim?" ... It's pigging obvious!

---

From: Tobias Conradi <[email-masked]>
Date: Thu, 23 Oct 2014 18:37:45 +0200

> "substantive" change up to the client for now - to keep the protocol simple

The most simple protocol does nothing.

> detection is needed we can implement that as an extension.

That would be
http://tools.ietf.org/html/draft-ietf-tzdist-service-02#section-4.1.7
and
http://tools.ietf.org/html/draft-ietf-tzdist-service-02#section-10

And
http://tools.ietf.org/html/draft-ietf-tzdist-service-02#section-10.2
10.2 Initial Time Zone Data Distribution Service Registries
with
10.2.1. Actions Registry
10.2.2. Action Parameters Registry

But with these, it was pointed out that there are inconsistencies.

All actions that have been presented so far "get" some data and don't,
e.g. alter data on the server.

And Stephen Colebourne wrote at
http://www.ietf.org/mail-archive/web/tzdist/current/msg00682.html

> It is with this best practice that
> I find "?action=" to be just plain wrong,

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Tobias Conradi <[email-masked]>
Date: Thu, 23 Oct 2014 18:40:59 +0200

On Thu, Oct 23, 2014 at 6:26 PM, Lester Caine <[email-masked]> wrote:
---re-insert--
--

> "Source for that claim?" ... It's pigging obvious!

If you can provide a link to that obvious source, please provide the link.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Eliot Lear <[email-masked]>
Date: Thu, 23 Oct 2014 18:52:23 +0200

> The most simple protocol does nothing. 

And the same can be said as the most complex.  Let's please avoid
overstating the case.  Occam's razor should apply.  And so we should
limit creeping featurism, unless there is clear value to a fair
percentage of the users.

Eliot

---

From: Tobias Conradi <[email-masked]>
Date: Thu, 23 Oct 2014 19:05:10 +0200

On Thu, Oct 23, 2014 at 6:52 PM, Eliot Lear <[email-masked]> wrote:
> And so we should

What is the fair percentage for the purpose of TZDIST, 5%, 10%, 20%, 50%?

IIRC Lester, me and maybe others, talked about clocks that are fixed
to a building and only display the current time. They benefit from
restricting the amount of data that is exchanged.

Is there any evidence that for the action "expand" "there is clear
value to a fair percentage of the users." while for the proposed
changedsince there is not?

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Lester Caine <[email-masked]>
Date: Thu, 23 Oct 2014 18:51:16 +0100

>>> A "material" change to the results of using a changed set of data must

The obvious source is that I have said it! Is there ANY case when not
making correct new data available and advertising the the fact makes any
sense? Why do I need to add any more to the statement of fact?

---

From: Tobias Conradi <[email-masked]>
Date: Thu, 23 Oct 2014 20:41:11 +0200

On Thu, Oct 23, 2014 at 7:51 PM, Lester Caine <[email-masked]> wrote:
> The obvious source is that I have said it!
OK, thanks.

> Is there ANY case when not
> sense?
The initial statement was

>>>any action to be made to review the effects of a change.

There are cases, where "correct new data" for something that not "
simply amends documentation" are irrelevant for some users.

All data that a tower clock in Moscow does not need is irrelevant for
that tower clock. E.g.
- a change to historic data,
- a change to data after the next transition date,
- a change of TZID aliases
- a change of TZ names, other than the TZID that makes the connection
to the TZDIST, if any

>Why do I need to add any more to the statement of fact?
I didn't look like a statement of fact to me.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Lester Caine <[email-masked]>
Date: Thu, 23 Oct 2014 20:44:42 +0100

> - a change of TZ names, other than the TZID that makes the connection

My current plan of attack for a system for building control in an
apartment block would be simply to be using extract and monitoring the
next DST change date. I currently envisage a local server which will
provide a single TZID of data for the next period. The client devices
will perhaps check each night and only get an update if the predicted
offset has changed. I'm even thinking that a tzserver/local/ will give a
single set of data for the building ... but it will probably actually
provide the current time feed anyway so this is a little academic.

If I am asking for any more than that data, then there should be some
good reason, and any change within the truncation period asked for needs
to be forwarded.

As soon as one is asking for an 'un-truncated' view of the data, again
any change in that data needs to be forwarded. If your tower clock asks
for a full view of the data one supplies it even if it does not make
sense. We do not know why the client needs it, so at the end of the day
every change IS substantive if it is within the time period being
requested. It may not be 'material' to a change of predicted offset, but
it is material to the view of the data that was supplied initially.

This does not mean I don't accept that some means of trimming the level
of detail provide would be useful, but at present there is no documented
method to include any supplementary data anyway? Only the core tz data ...