Subject: Re: [Tzdist] [tz] Timezone in Brazil

From: Paul Eggert <[email-masked]>
Date: Sun, 11 Oct 2015 14:12:32 -0700

Lester Caine wrote:
> tzdb should only be published with a
> 1970 start date and anything prior to that is unreliable

No, many tzdata entries before 1970 are quite reliable.  True, tzdata entries 
tend to become less reliable the further back one goes in time, but this is 
merely a tendency.  For example, the data for England in 1915 is far more 
reliable than the data for Baja California state in 2015.

---

From: Lester Caine <[email-masked]>
Date: Sun, 11 Oct 2015 23:02:54 +0100

On 11/10/15 22:12, Paul Eggert wrote:
> No, many tzdata entries before 1970 are quite reliable.  True, tzdata
> entries tend to become less reliable the further back one goes in time,
> but this is merely a tendency.  For example, the data for England in
> 1915 is far more reliable than the data for Baja California state in 2015.

'MANY' ... but there is data in backzone which conflicts with the
non-backzone version despite being verified and relating to the very
material I am working with. Additionally material relating to local
standard times in the UK is well authenticated, but is not easy to
distinguish when all that is available is a 'Europe/London' rule set.
The only way to handle things currently IS to say "don't rely on your
computers offsets for any material prior to 1970" ... it may or may not
be correct.

-- 
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: Paul Eggert <[email-masked]>
Date: Sun, 11 Oct 2015 15:24:40 -0700

> 'MANY' ... but there is data in backzone

Sure, but backzone is published as part of tzdata, and it's easy to use; just 
set a switch in the Makefile.  And regardless of whether backzone is used, 
there's no good reason to require implementations to reject time stamps before 1970.

---

From: [email-masked]
Date: Mon, 12 Oct 2015 00:08:20 +0100

But you are always gambling that the client machine has actually compiled WITH backzone? If it is missing then data prior to 1970 is suspect.

Sent from my android device so quoting is crap ... need to kill these painful email clients!

---

From: Paul Eggert <[email-masked]>
Date: Sun, 11 Oct 2015 16:40:40 -0700

> But you are always gambling that the client machine has actually compiled WITH backzone? If it is missing then data prior to 1970 is suspect.

If backzone is used to build the tzdist server's data, then the server contains 
more data, some good and some questionable.  Some of the good data is before 
1970, and some after.  Some of the questionable data is before 1970, and some 
after.  In this sense, it's just the same as when backzone is not used.  So 
there's no good reason to require implementations to reject time stamps before 
1970 merely because backzone is being used (or is not being used).

I get the sense that you're trying to shoehorn backzone into a slot that it's 
not designed for.  It appears that you want some indication of how reliable data 
are.  There is no such indication anywhere in the formal part of tzdata, nor in 
tzdist, and this is true regardless of whether backzone is used.

---

From: Lester Caine <[email-masked]>
Date: Mon, 12 Oct 2015 09:51:44 +0100

On 12/10/15 00:40, Paul Eggert wrote:
>> But you are always gambling that the client machine has actually
>> compiled WITH backzone? If it is missing then data prior to 1970 is
>> suspect.
> 
> If backzone is used to build the tzdist server's data, then the server
> contains more data, some good and some questionable.  Some of the good
> data is before 1970, and some after.  Some of the questionable data is
> before 1970, and some after.  In this sense, it's just the same as when
> backzone is not used.  So there's no good reason to require
> implementations to reject time stamps before 1970 merely because
> backzone is being used (or is not being used).
> 
> I get the sense that you're trying to shoehorn backzone into a slot that
> it's not designed for.  It appears that you want some indication of how
> reliable data are.  There is no such indication anywhere in the formal
> part of tzdata, nor in tzdist, and this is true regardless of whether
> backzone is used.

But all YOU are saying there is exactly what *I* am saying ... you can't
use tzdb for reliable conversions prior to 1970! ... because the data is
unreliable. There IS a good reason to reject if it is important that the
correct data is used for normalizing. In my own case I need some way to
ensure that backzone IS in use by clients since this provide a lot more
correct set of rules than a generic result, but as you say ... there is
simply no way of knowing just what the client has PRIOR TO 1970! It is a
gamble when it should clearly identify the source ... so that even
faulty results can be reliably recreated.

I would prefer that the backzone data was ALWAYS included and then one
can guarantee that the client has a complete set of rules, many of which
are more accurate prior to 1970 than if that additional data is simply
ignored. What would be safer is if the extra UK aliases simply did not
exist if they are not returning the data that they should be!

---

From: Paul Eggert <[email-masked]>
Date: Mon, 12 Oct 2015 09:55:44 -0700

On 10/12/2015 01:51 AM, Lester Caine wrote:
> you can't
> use tzdb for reliable conversions prior to 1970!

Not so. Absolutely you can use tzdata, for places like Europe/London in 
1915 where the information has been checked and double-checked. True, 
tzdata is unrelable for *some* locations before 1970, but it's also 
unreliable for some locations *after* 1970. If you want guaranteed 
reliability, you're not going to find it in tzdata, nor in any other 
database out there.

Again, the problem here is that you appear to be asking for tzdata to be 
something that it's not, e.g., to be divided into "reliable" and 
"unreliable" sections. It's not divided that way. It's divided into 
"in-scope" (most data) and "out-of-scope" (backzone) sections. This 
approach is easy to implement, because it's easy to test whether data 
entries are in scope. Dividing it into "reliable" and "unreliable" 
sections would be much harder to implement, since it would require some 
sort of measurement of "reliability" (a notion whose very definition 
would be controversial), together with an agreed-on threshold for what 
is "reliable enough". I'm not saying it would be impossible, just hard 
to do; and nobody is volunteering to do it. Certainly neither tzdata nor 
tzdist supports this sort of notion now.

> In my own case I need some way to
> ensure that backzone IS in use by clients

You can give them a copy of backzone, then, and have them compute with 
it. Or if you're using tzdist, do something similar with the servers.

There's no guarantee that clients and/or servers will have any 
particular version of tzdata. If you want a guarantee like that, the 
easiest way to implement it is to give the clients or servers exactly 
the data you want them to use, and have them use that.

---

From: Lester Caine <[email-masked]>
Date: Mon, 12 Oct 2015 19:40:20 +0100

On 12/10/15 17:55, Paul Eggert wrote:
>> you can't use tzdb for reliable conversions prior to 1970!
> 

Europe/Jersey and Europe/Guernsey did not follow London during the war
and other backzone aliases also vary across Europe in that period
Europe/Belfast followed Ireland pre 1968 and like Europe/Isle_of_Man
switched to a standard time at a different date to the rest of the UK.
All only little point's, but important differences in the pre 1970
chronology!

These differences are validated data ... but missing if a distribution
simply switches backzone off and while yes some backzone material is
unverified, this particular section is very much verified. So how does
one recognise that those aliases are returning the correct pre-1970 data
and not just mirroring Europe/London or one of the other generic
European rule sets?

---

From: Doug Royer <[email-masked]>
Date: Mon, 12 Oct 2015 14:44:24 -0600

On 10/12/2015 12:40 PM, Lester Caine wrote:
>> Not so. ...

The whole point of this protocol is to start gathering reliable data and
distributing it.

There is an update process that can be followed for submissions. See
10.1 in the draft. I am sure that 'corrections' when found can also be
submitted for review.

Should a corrections process be specifically mentioned in the draft?

I would suggest whoever finds errors in the database create the
'correct' TZ data and submit it for review.

-- 

Doug Royer - (http://K7DMR.us / http://DougRoyer.US)
[email-masked]
714-989-6135