Subject: Re: [Tzdist] addressing issue 18: " removal of timezones?"

From: Tim Parenti <[email-masked]>
Date: Wed, 1 Oct 2014 19:34:10 -0400

On 24 September 2014 12:37, Daniel Migault <[email-masked]> wrote:

> It is not clear to me whether the following text is a recommendation or a
> statement.
> "It is common for clients to silently substitute UTC for withdrawn or
> unknown time zone names."
>
> I am wondering if we should add some text whether such practices are
> recommended or not, and if an error or a specific time zone
> (non-existing-time-zone) shoudl be used.
>

While it is out-of-scope for us to mandate that such practices be either
undertaken or avoided, given the concerns of many over the repercussions of
withdrawing zone names, I think we should add text to discourage it.
Perhaps this is as simple as:

OLD:
It is common for clients to silently substitute UTC for withdrawn or
unknown time zone names.

NEW:
Since it is common for clients to silently substitute UTC for withdrawn or
unknown time zone names, the outright deletion of time zone names is
discouraged.

--
Tim Parenti

---

From: Lester Caine <[email-masked]>
Date: Thu, 02 Oct 2014 03:12:00 +0100

On 02/10/14 00:34, Tim Parenti wrote:
> NEW:
> Since it is common for clients to silently substitute UTC for withdrawn
> or unknown time zone names, the outright deletion of time zone names is
> discouraged.

This still assumes that silently changing what has been previously
supplied with something totally unrelated is acceptable practice!

Unknown references will always get an 'invalid' and it is better that
'withdrawn' ones are treated the same way. The problem with even that
statement is that it implies that retaining the name and switching it to
return UTC silently is acceptable.

-- 
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, 2 Oct 2014 04:40:53 +0200

On Wed, Sep 24, 2014 at 6:37 PM, Daniel Migault <[email-masked]> wrote:
> Hi,
>
> This thread has had quite a lot of cross discussions. It seems that most
> people agree with the following text:
>
> "If a time zone X is deleted, it is common for a publisher to make its
> identifier an alias for some other time zone Y
No proof given.

>, to cater to clients that may
> still be using X's identifier; because this changes Y, it can be discovered
> by a "list" with "changedsince".  In contrast, the outright deletion of X
> (with no other change) requires a "list" without "changedsince" to be
> discovered."
What does "outright" add in a technical document?

> unknown time zone names."
It is a statement with no proof presented.

> (non-existing-time-zone) shoudl be used.

definition of time zone:
1) territorial entity (pre-tzdist)
2) description of practices (tzdist-service)
3) to 2) it is added "non-existing description of practices"

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Tobias Conradi <[email-masked]>
Date: Thu, 2 Oct 2014 04:44:44 +0200

On Wed, Sep 24, 2014 at 9:15 PM, Paul Eggert <[email-masked]> wrote:
> On 09/24/2014 09:37 AM, Daniel Migault wrote:
>>
>>
> When I wrote it I thought of it as a statement, i.e., information that could
> be of use to authors of client or server software.  It'd be OK to turn it
> into a recommendation.
No it would not be OK.

> tzdist should not recommend an error
Oh yes, it should

>, or any specific time zone other than
> UTC.
Oh why is UTC more correct than any other?

> That would disagree with the common practice of silently substituting
> UTC.
Oh, where is the proof for that common practice?

>  There's no reason to disallow this common practice.
There is plenty.

I hope tzdist will not repeat all the mistakes of the Eggert/IANA time
zone database.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Tobias Conradi <[email-masked]>
Date: Thu, 2 Oct 2014 04:57:25 +0200

On Wed, Sep 24, 2014 at 11:38 PM, Lester Caine <[email-masked]> wrote:
> Common practice at one time was to only use two digits for the year. In
> some areas we are still dealing with the fallout!
That can happen even if common practice is best practice known at a
certain point in time.

But what is the aim in tzdist? Find a best practice or perpetuate a
common practice? Are there other common practices that are better?

> but rather than simply now returning 'invalid' I feel
> the server SHOULD return a valid replacement somehow so that the device
> can continue working? If it has to switch to UTC then I would also
> recommend that the device would simply switch off for safety reasons!

But the plan was to "silently substitute" so the device would not know
it has been fooled.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Tobias Conradi <[email-masked]>
Date: Thu, 2 Oct 2014 04:59:36 +0200

On Thu, Oct 2, 2014 at 1:34 AM, Tim Parenti <[email-masked]> wrote:

> OLD:
> It is common for clients to silently substitute UTC for withdrawn or unknown
> time zone names.
>
> NEW:

I propose to delete the word "outright". It makes the WG look silly.
-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Paul Eggert <[email-masked]>
Date: Wed, 01 Oct 2014 21:06:16 -0700

Tim Parenti wrote:
> given the concerns of many over the repercussions of
> withdrawing zone names

The question is whether tzdist should document what some users wish for, or what 
actually happens.  What actually happens is that names get withdrawn on occasion.

Saying that zone names should be permanent would be like saying that URLs or 
domain names should be permanent.  It's nice to dream but it's not what actually 
happens, and clients should be prepared for real-world behavior.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 02 Oct 2014 06:33:58 +0200

Paul,

On 10/2/14, 6:06 AM, Paul Eggert wrote:
> The question is whether tzdist should document what some users wish
> for, or what actually happens.  What actually happens is that names
> get withdrawn on occasion.
>
> Saying that zone names should be permanent would be like saying that
> URLs or domain names should be permanent.  It's nice to dream but it's
> not what actually happens, and clients should be prepared for
> real-world behavior.

I think we are mixing up API and protocol.  If the protocol returns an
error, the client can decide to use UTC or to notify the user or to take
other action (invoke a different location service or whatever).  But if
the protocol doesn't return an error, the client has no choice in the
matter.

Eliot

---

From: Tim Parenti <[email-masked]>
Date: Thu, 2 Oct 2014 12:21:51 -0400

> supplied with something totally unrelated is acceptable practice!

No such assumption or assertion is made in the text above.  I agree that
it's bad practice for clients to silently assume anything about such zones,
but I aimed above to merely describe the repercussions of possible (and
unfortunately widespread) client behavior so that server implementers are
aware and discouraged from treating deleted zones the same as undefined
zones.

On 2 October 2014 00:06, Paul Eggert <[email-masked]> wrote:

> Saying that zone names should be permanent would be like saying that URLs
> or domain names should be permanent.  It's nice to dream but it's not what
> actually happens, and clients should be prepared for real-world behavior.

I wasn't arguing this either.  I think it's probably beyond our scope to
insist that clients ask the user how to interpret withdrawn zone names,
although that is definitely what any responsible client should be doing in
these cases.

> the protocol doesn't return an error, the client has no choice in the

This, I think, gets to the problem, while staying within our scope.  If I
recall correctly, the protocol already returns an error for "unknown" zone
names, but does not currently make a distinction between identifiers that
were withdrawn and identifiers that never had data to begin with.

I'm not convinced we need to make such a distinction.  If a client has
previously downloaded data for an identifier, and that identifier is later
withdrawn, upon seeking update, the client will receive an "unknown zone
identifier" error.  This should be sufficient information for the client to
detect or otherwise infer the deletion.

Again, any reasonable client implementation would then ask the user what it
should do, rather than silently assuming *anything* about the zone, but I
firmly believe that that is outside our scope here.

--
Tim Parenti

---

From: Lester Caine <[email-masked]>
Date: Thu, 02 Oct 2014 17:37:21 +0100

> the protocol doesn't return an error, the client has no choice in the

That was my point. We have no control over what data is transferred, and
while it would be nice to assume that third party publishers will
provide correct information it is out of scope, so all we can ensure is
that something that might affect a currently active offset is flagged in
some way?

I would consider now that having an unreliable source of data is just
something that we have to flag other ways, and it is a separate problem
outside of tzdist how to identify sources that can be relied on to
provide stable historic data.

---

From: Daniel Migault <[email-masked]>
Date: Thu, 23 Oct 2014 17:33:03 +0200

Dear Friends and colleagues,

The current text of version 02 related to time zone deletion is as
follows. Can you please confirm it has reached consensus?

BR,

Daniel

 Note that there are two approaches a publisher might take to "delete"
   a time zone.

   a.  The common case is for a publisher to make the identifier of the
       "deleted" time zone an alias for some other time zone, to cater
       to clients that might still be using the original identifier.
       Because this changes the details about the time zone being
       aliased to, it can be discovered by a combination of a "list"
       action with the "changedsince" parameter.

   b.  The second case is for the publisher to do an "outright" deletion
       of a time zone without any replacement alias for its identifier.
       To detect such a change, a "list" action without "changedsince"
       has to be done by the client.  Since it is common for clients to
       silently substitute UTC for withdrawn or unknown time zone names,
       the "outright" deletion of time zone names is discouraged.

On Thu, Oct 2, 2014 at 6:37 PM, Lester Caine <[email-masked]> wrote:

> _______________________________________________
> Tzdist mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist
>

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Paul Eggert <[email-masked]>
Date: Thu, 23 Oct 2014 08:55:59 -0700

On 10/23/2014 08:33 AM, Daniel Migault wrote:
 >        "deleted" time zone an alias ...
 >
 >    b.  The second case is for the publisher to do an "outright" 
deletion ...
 >        Since it is common for clients to

I'm afraid the last sentence is still too strong.  In theory (a) and (b) 
both cause a client to silently substitute a new behavior for an old 
one, and the new behavior may not be what users want, so in that sense 
(a) and (b) are both dangerous and should both be discouraged.  In 
practice, though, there are sometimes good reasons to do (b), just as 
there are sometimes good reasons to do (a), and tzdist should not 
discourage (b), just as it does not discourage (a).

To fix this problem I propose changing this:

   Since it is common for clients to silently substitute UTC for 
withdrawn or unknown time zone names, the "outright" deletion of time 
zone names is discouraged.

to this:

   Publishers should take into account the fact that the "outright" 
deletion of time zone names typically causes clients to silently 
substitute UTC for withdrawn or unknown time zone names.

---

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

> substitute UTC for withdrawn or unknown time zone names.

The real problem here is not the deletion of the data set. What the
client does to solve the problem is up to the client, and while
'switching to UTC' may be the current effect on current software, in
future I would certainly design my clients simply to retain the last
supplied offset. The client ideally need some automated way to obtain a
new TZID but that is outside scope!

" Publishers should take into account the fact that the "outright"
deletion of time zone names will cause problems to simple clients and so
linking to a suitable alternate data set is preferable."

Making assumptions about using UTC has no relevance here!

---

From: Tim Parenti <[email-masked]>
Date: Mon, 27 Oct 2014 12:26:22 -0400

> linking to a suitable alternate data set is preferable."

Per discussion at our virtual meeting of 24 October 2014, I propose the
following for section 4.2.3 of draft-ietf-tzdist-service-02, in its
entirety:

OLD:

A secondary service or a client caching all time zone data needs to
periodically synchronize with a server.  To do so it would issue a "list"
action with the "changedsince" parameter set to the value of the datestamp
returned by the last synchronization.  The client would again preserve the
returned datestamp for subsequent use.  Each time zone in the returned list
can then be fetched and stored locally.

Note that there are two approaches a publisher might take to "delete" a
time zone.

a.  The common case is for a publisher to make the identifier of the
"deleted" time zone an alias for some other time zone, to cater to clients
that might still be using the original identifier.  Because this changes
the details about the time zone being aliased to, it can be discovered by a
combination of a "list" action with the "changedsince" parameter.

b.  The second case is for the publisher to do an "outright" deletion of a
time zone without any replacement alias for its identifier.  To detect such
a change, a "list" action without "changedsince" has to be done by the
client.  Since it is common for clients to silently substitute UTC for
withdrawn or unknown time zone names, the "outright" deletion of time zone
names is discouraged.

NEW:

A secondary service or a client caching all time zone data needs to
periodically synchronize with a server.  To do so it would issue a "list"
action with the "changedsince" parameter set to the value of the datestamp
returned by the last synchronization.  The client would again preserve the
returned datestamp for subsequent use.  Each time zone in the returned list
can then be fetched and stored locally.

Since the behavior of clients attempting to use withdrawn, unknown, or
otherwise nonexistent time zone identifiers is undefined, publishers SHOULD
NOT delete previously published time zone identifiers outright.  Instead,
publishers SHOULD alias deprecated identifiers to a suitable alternative.
Because aliasing changes the details about the time zone being aliased to,
it can be discovered in the same manner as above.  When a client
application finds that it is using a nonexistent time zone identifier, it
SHOULD inform the user so that they may take any desired corrective action.

* * *

I think this new text touches all the important points we agreed upon on
the call — why deletion is a problem, what to do instead — while avoiding
assertions about both which publisher actions and which client reactions
are common or uncommon.  Additionally, since the new text sticks to what
behavior SHOULD be undertaken, we can avoid repeating how the different
types of deletions would be detected.

You may notice that I expanded my proposal a bit with the last sentence,
since I feel it might still be within our scope to describe a "best
practice" for clients.  Using a "SHOULD" allows the simplest devices to
just carry on as they please, but for an application of sufficient
complexity (e.g., a calendaring application), if it is dealing with a
deleted zone, I think most would want it to let them know.

If others think that last sentence is better left out, I'd be fine
excluding it, but I present it for comment with the rest of the above as a
"new starting point".

--
Tim Parenti

---

From: Paul Eggert <[email-masked]>
Date: Mon, 27 Oct 2014 11:56:05 -0700

On 10/27/2014 09:26 AM, Tim Parenti wrote:
> Using a "SHOULD" allows the simplest devices to just carry on as they 
> please, but for an application of sufficient complexity (e.g., a 
> calendaring application), if it is dealing with a deleted zone, I 
> think most would want it to let them know.

I'd rather omit that SHOULD sentence, since it contradicts common 
current practice in the world of tz-using clients.

It strikes me that any well-written calendaring application should be 
able to notify users of any change to time zone information, not merely 
changes due to withdrawn identifiers.  If tzdist is going to make 
recommendations along these lines, it should issue a general 
recommendation along those lines, not a specific recommendation about a 
particular less-likely sort of change.  And it should make it clear that 
the recommendation applies only to clients where notifying the user is a 
reasonable thing to do (often it is not).

---

From: Lester Caine <[email-masked]>
Date: Tue, 28 Oct 2014 06:43:43 +0000

> reasonable thing to do (often it is not).

'It should make it clear that ...'
Which is why I tried to write a simple warning rather than getting
bogged down with anything heavier. It is the clients problem to deal
with so I think my second paragraph is heavy enough to cover it.

Just to be a little more prices as my intention may have been lost ...

NEW
-----------------------
A secondary service or a client caching all time zone data needs to
periodically synchronize with a server.  To do so it would issue a
"list" action with the "changedsince" parameter set to the value of the
datestamp returned by the last synchronization.  The client would again
preserve the returned datestamp for subsequent use.  Each time zone in
the returned list can then be fetched and stored locally.

Publishers should take into account the fact that the "outright"
deletion of time zone names will cause problems to simple clients and so
linking to a suitable alternate data set is preferable.
-----------------------

Tobias has already pointed out that not all of the underlying data may
be visible ( is this just a language problem Tobias? ) and it may be
that a server IS only providing a limited set of data, so a TZID may
drop out of their remit to supply which will appear as a deleted entry
to the client. That may be a case for some alternate action but it is a
discussion between 'server' and 'user' outside the scope of tzdist?

---

From: Tim Parenti <[email-masked]>
Date: Wed, 29 Oct 2014 02:04:04 -0400

> linking to a suitable alternate data set is preferable.

Lester, this seems to be the exact same text as your earlier suggestion,
which it seemed needed to be further clarified based on the consensus from
our call.

On 27 October 2014 14:56, Paul Eggert <[email-masked]> wrote:

> I'd rather omit that SHOULD sentence, since it contradicts common current
> practice in the world of tz-using clients.
>
> It strikes me that any well-written calendaring application should be able
> to notify users of any change to time zone information, not merely changes
> due to withdrawn identifiers.  If tzdist is going to make recommendations
> along these lines, it should issue a general recommendation along those
> lines, not a specific recommendation about a particular less-likely sort of
> change.  And it should make it clear that the recommendation applies only
> to clients where notifying the user is a reasonable thing to do (often it
> is not).
>

Paul, you make good points here, which my narrower focus on this issue
missed.  I agree that if we are to make any such recommendation about how
clients should handle changes, it should be at a higher level, applicable
to all changes, but only when such an expectation is reasonable.  So I
withdraw the final sentence from my recommended text at
http://www.ietf.org/mail-archive/web/tzdist/current/msg00868.html and leave
the rest for comment or consensus.

If the group thinks we should work such a client behavior recommendation
into the text, I can look into where that might fit better.

--
Tim Parenti