Subject: [Tzdist-bis] negative DST etc. (comments on draft-murchison-tzdist-tzif-02)

From: Paul Eggert <[email-masked]>
Date: Fri, 25 May 2018 18:34:27 -0700

A few more comments on the latest draft.

"It is assumed that a reliable and accurate source is available." I 
suggest removing this sentence. As the tzdb theory.html file says, "The 
tz database is not authoritative, and it surely has errors." The TZif 
spec shouldn't need to assume data reliability or accuracy.

"Daylight Saving Time (DST):  The time according to a location's law or 
practice, adjusted forward from standard time during summer months to 
gain more evening daylight." Some locations observe DST in non-summer 
months, and some observe negative daylight saving time to gain morning 
daylight. This has long been supported in the reference implementation 
and is used in tzdata 2018e (see the Eire rules and Europe/Dublin for 
one example). Although some tzdata downstream clients don't support 
negative DST, as far as I know the main (and only) example of this is 
are Java-based clients that do not use TZif so it should not be an issue 
for TZif itself. So I suggest changing this to: "Daylight Saving Time 
(DST): The time according to a location's law or practice, adjusted as 
necessary from standard time. The adjustment may be positive, negative 
or zero."

"Standard Time:  The time according to a location's law or practice, 
unadjusted for changes such as Daylight Saving Time." I suggest removing 
"changes such as", because the format makes no provision for any 
adjustments other than DST.

---

From: Lester Caine <[email-masked]>
Date: Sat, 26 May 2018 11:54:51 +0100

> spec shouldn't need to assume data reliability or accuracy.

tzdist opened up the option for different data publishers. My problem 
with the current source is that one may or may not get known reliable 
data pre 1970. If TZ is being used as the data source, then tzdist 
SHOULD flag this as ONLY accurate back to 1970 as aliased time zone 
identifiers will be using data which may be wrong prior to 1970. This 
leaves a major problem for users who are looking to manage pre-1970 data 
as there is no authoritative source for pre-1970 data. Including the 
'backzone' file will add some 'reliable and accurate' pre-1970 data and 
other timezone rules sets DO include accurate transitions ... we just 
don't have any reliable way of knowing that unless the tzdist publisher 
provides accurate start dates for each supplied rule set?

-- 
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: Eliot Lear <[email-masked]>
Date: Sat, 26 May 2018 08:52:27 -0400

Well I do think this is a bit of an issue, but we need to be careful to
circumscribe the problem.  Not for the draft, but just at least for our
own discussion purposes, here is my own thinking:

  * the TZIF draft is a transfer format.  It doesn't speak to accuracy,
    nor does it speak to sources.
  * Source identification is generally tied to authentication of the
    data.  I think it's worth discussing in Security Considerations that
    while this is beyond the scope of a transfer format, it may be
    useful for sources to sign the data, and then refer to CMS.
  * If someone wants to do a separate draft to define a CMS
    message-type, that could happen separately.

Doing otherwise might lead us deep into murky waters, to the point where
we accomplish a pretty useful task of documenting existing practice,
something that I believe we could do very quickly.

To this end, I agree with Paul that the statement about assumptions of
accuracy should be removed.

Eliot

On 26.05.18 06:54, Lester Caine wrote:
>> suggest removing this sentence. As the tzdb theory.html file says,
>> "The tz database is not authoritative, and it surely has errors." The
>> TZif spec shouldn't need to assume data reliability or accuracy.
>
> leaves a major problem for users who are looking to manage pre-1970
> data as there is no authoritative source for pre-1970 data. Including
> the 'backzone' file will add some 'reliable and accurate' pre-1970
> data and other timezone rules sets DO include accurate transitions ...
> we just don't have any reliable way of knowing that unless the tzdist
> publisher provides accurate start dates for each supplied rule set?
>

---

From: Eliot Lear <[email-masked]>
Date: Sat, 26 May 2018 09:06:52 -0400

On 26.05.18 08:52, Eliot Lear wrote:
>
> Doing otherwise might lead us deep into murky waters, to the point
> where we accomplish a pretty useful task of documenting existing
> practice, something that I believe we could do very quickly.
>
>

Erm.  ... to the point where we DON'T accomplish a pretty useful task...

---

From: Lester Caine <[email-masked]>
Date: Sat, 26 May 2018 15:39:28 +0100

>     nor does it speak to sources.
Just to clarify ...
Is the tzif packet only handling a complete dump of the TZ database? So 
it's use with tzdist is only for a full data 'download'? There will be 
no provision to do a binary download if a single time zone rule-set has 
changed?

> accuracy should be removed.
I can understand keeping all of the source management at the tzdist 
level, and managing incompatibilities such as the inclusion or not of 
backzone data happens outside the transfer mechanism. The one thing that 
we SHOULD be targeting is making it easy for a user to establish at 
least that there IS a need to update a rule-set, so that they can then 
check other data using those time zones. Simply dumping a complete new 
set of data 99.99% of which is unchanged may be the easy option, but it 
does not need tzdist?

---

From: Paul Eggert <[email-masked]>
Date: Sat, 26 May 2018 10:41:29 -0700

Lester Caine wrote:

> Is the tzif packet only handling a complete dump of the TZ database? So it's use 
> with tzdist is only for a full data 'download'? There will be no provision to do 
> a binary download if a single time zone rule-set has changed?

No, in the latest draft it's just the opposite. TZif specifies only the data for 
a single Zone (in zic parlance). For example, it can specify the data for 
America/Los_Angeles, but if you want multiple zones you need multiple TZif files.

We have talked about a way of getting a full data download, but that'd be quite 
a change from what is in the draft spec now.

> The one thing that we SHOULD be targeting is 
> making it easy for a user to establish at least that there IS a need to update a 
> rule-set, so that they can then check other data using those time zones.

For existing time zones there is already a mechanism to do that, which is hinted 
at in the current draft; look for "ETag". It would be helpful to describe the 
mechanism more explicitly in the example, for people not familiar with HTTP caching.

The current draft addresses only single zones, so it doesn't address the issue 
of how a client is supposed to find out about new zones or other such metadata 
issues, such as last year's change when Africa/Juba became a Zone as opposed to 
being a Link.

> This leaves a major problem for users who are looking to manage pre-1970 data as there is no authoritative source for pre-1970 data.

The problem is more general, as there is no authoritative source for any of this 
data, not even the post-1970 data. The main page for tzdb says, "The tz code and 
data are by no means authoritative." Its theory page says, "The tz database is 
not authoritative, and it surely has errors." These repeated statements are 
there for good reason. Neither tzdb nor the IANA has any legal authority 
whatsoever. Also, we know that there are errors in the post-1970 tz data, it's 
just that we don't know how to fix the errors. This is why the TZif spec should 
not imply that tzdb is authoritative or correct for civil-time clocks.