<div dir="ltr"><div dir="ltr"><div dir="ltr" class="gmail_signature"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">---------- Forwarded message ----------<br>From: Robert Elz <<a href="mailto:kre@munnari.oz.au" target="_blank">kre@munnari.oz.au</a>><br>To: Lester Caine <<a href="mailto:lester@lsces.uk" target="_blank">lester@lsces.uk</a>><br>Cc: <a href="mailto:tz@iana.org" target="_blank">tz@iana.org</a><br>Bcc: <br>Date: Wed, 03 Jun 2020 19:31:43 +0700<br>Subject: Re: [tz] How good is pre-1970 time zone history represented in TZ database?<br>    Date:        Wed, 3 Jun 2020 12:22:32 +0100<br>    From:        Lester Caine <<a href="mailto:lester@lsces.uk" target="_blank">lester@lsces.uk</a>><br>    Message-ID:  <<a href="mailto:3576438c-e0bd-7188-2153-43d80e9054b8@lsces.uk" target="_blank">3576438c-e0bd-7188-2153-43d80e9054b8@lsces.uk</a>><br><br>There are two kinds of<br>changes that may be made to a zone.   One affects only future timestamps,<br>and is the common old garden variety "government interference" or however<br>you think of it.  These are far and away the most common changes.  While<br>when we have insufficient notification of a change, it may be applied<br>retrospectively, when that has happened, everyone tends to be very aware<br>that there were bad time conversions for a while.   In any case, old<br>historic stored data isn't affected at all by this kind of change, it<br>is as valid (or not) after the change as it was before.<br></blockquote><div><br></div><div>You can also have data recorded in the past which refers to the future, so even</div><div>a change that affects only future timestamps can still invalidate existing</div><div>stored data.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The second kind of change is a correction to historic data.  This happens when<br>we discover an error in what was present (and these days, almost only ever<br>affects pre-1970 timestamps).<br><br>In those, if someone had stored the UTC converted form of some local timestamp,<br>then after the correction they wouldn't get back the data that was originally<br>used to produce it.<br><br>The problem there is having discarded the original data instead of retaining<br>it.   Always retain the original source data.   Then by all means, when<br>computing, convert timestamps from their various local values to UTC so<br>they can be more easily correctly ordered (or whatever) but use those<br>converted values only for transient computations.   Store the original.<br>Always.<br><br>If that is done correctly, then after a correction to old data, the<br>results might be different than they were before - but that's only because<br>they were wrong before, and (hopefully) better after the fix.<br></blockquote><div><br></div><div>I agree 100%.  I've been struggling for years to really get my head wrapped</div><div>around this stuff, and finally decided to create a formal model using abstract</div><div>data types.  I'm finding that approach to be quite helpful, so I wrote it up in a</div><div>couple of essays that folks on this list might find interesting.  In fact, the folks</div><div>on this list may well be the *only* people who would find them interesting.  :-)</div><div><br></div><div>The first is aimed at the general programmer, but it introduces the fundamental</div><div>concepts:</div><div><a href="https://drive.google.com/file/d/1WntAyhIawYtbL2k3fPE71cM9EFkVCJGQ/view?usp=sharing" target="_blank">https://drive.google.com/file/d/1WntAyhIawYtbL2k3fPE71cM9EFkVCJGQ/view?usp=sharing</a></div><div><br></div><div>The second is aimed at time geeks and goes much deeper into the underlying theory:</div><div><a href="https://drive.google.com/file/d/1aOj9YeDFUST0lQFXZiUsCSmxjnzlbIe4/view?usp=sharing" target="_blank">https://drive.google.com/file/d/1aOj9YeDFUST0lQFXZiUsCSmxjnzlbIe4/view?usp=sharing</a><br></div><div><br></div><div>These are still in draft form, but I hope others find some value in them.  (Teaser:</div><div>the model makes no reference to years, days, hours, or seconds.  How's that for</div><div>abstract?)</div><div><br></div><div>What is rather interesting (and reassuring) is that the formal model ends up telling</div><div>us pretty much what this thread has been saying:  store original data.  However,</div><div>by looking at things in terms of abstract data types, you can easily see *why* you</div><div>need to do that without having to resort to specific examples, and many seemingly</div><div>unrelated cases can be seen to be special cases of the same underlying phenomenon.</div><div>The model also points you to the very specific places in your design and code</div><div>where you have to watch out for problems.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The only time it makes sense to store timestamps in other than the original<br>form is when we *know* that the conversion is correct (and hence, no later<br>correction will change it).   For users of tzdata that really only applies<br>to post-1970 timestamps.<br></blockquote><div><br></div><div>When exactly do we *know* anything, I mean really for sure?</div><div><br></div><div>Imagine yourself back in 1966.  UTC has been chugging along</div><div>nicely for five years, providing a well-behaved predictable time</div><div>standard.  We know it's never going to change.</div><div><br></div><div>Now it's 1967.  Oops, the name just changed.  Well, that doesn't</div><div>really count, a rose by any other name ...</div><div><br></div><div>Now it's 1972.  Oops again, we just added a leap second, and</div><div>there are more on the way.  Sorry unix time_t, your fundamental</div><div>assumption was just revoked -- and so for the next 50 years, nearly</div><div>every computer on the planet will stubbornly refuse to accept the</div><div>existence of leap seconds.</div><div><br></div><div>Never say never.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">---------- Forwarded message ----------<br>From: Robert Elz <<a href="mailto:kre@munnari.oz.au" target="_blank">kre@munnari.oz.au</a>><br>To: Lester Caine <<a href="mailto:lester@lsces.uk" target="_blank">lester@lsces.uk</a>><br>Cc: <a href="mailto:tz@iana.org" target="_blank">tz@iana.org</a><br>Bcc: <br>Date: Wed, 03 Jun 2020 23:48:42 +0700<br>Subject: Re: [tz] How good is pre-1970 time zone history represented in TZ database?<br>    Date:        Wed, 3 Jun 2020 16:02:45 +0100<br>    From:        Lester Caine <<a href="mailto:lester@lsces.uk" target="_blank">lester@lsces.uk</a>><br>    Message-ID:  <<a href="mailto:3b7f0c78-4dd7-0f2e-a8e3-2b24401e7e1c@lsces.uk" target="_blank">3b7f0c78-4dd7-0f2e-a8e3-2b24401e7e1c@lsces.uk</a>><br><br>  | I came into this 20 years ago<br><br>I've been involved with it for longer than that - back to my first<br>unix experience, in '76, where the US tz rules were compiled into the<br>code, and most people in AU simply adjusted their computer's clock<br>(their offset from UTC) 4 times a year (when the US switched summer time<br>on and off, and when AU did - and yes, that meant that the generated GMT<br>timestamps were wrong, most of the time).   From that (a bit later) I was<br>responsible for the mess that existed until ado invented tzdata (and yes,<br>I mean the 2nd arg to gettimeofday()).<br></blockquote><div><br></div><div>You make me look like a newbie.  I first got into this seriously in 1997 while</div><div>updating legacy systems to handle Y2K.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>From all of this I have learned that time is hard.   Really hard.<br><br>Many people believe that since they learned to tell the time when<br>they were 4 or 5 years old, and have been doing it ever since, they<br>know all there is to know.   That's sad...<br></blockquote><div><br></div><div>See the discussion of seduction and polar bears in the first essay</div><div>linked above.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">  | now while working with a data archive<br>  | which has now been simply dumped because we had no idea what rules were<br>  | used to produce the normalised data.<br><br>That's a pity, byt sometimes past mistakes simply come back to bite,<br>and sometimes bite hard.   Note that the error there was normalising the<br>data, if that hadn't been done, none of the rest of it would matter,<br>you'd now have the original data and could manipulate it however seems<br>best, for now, regardless of what anyone did with it decades ago (and if<br>you get it all wrong, future generations could cope, because they'd also<br>still have the original data, and can fix any errors).<br><br>  | Nowadays yes it does make sense to<br>  | store both an original time and a normalised time,<br><br>No, it doesn't, just the original, plus ...<br><br>  | along with a location,<br><br>yes, something which can be mapped into a timezone - and as accurate<br>a location as possible.<br><br>  | and a record of which version of rules was used to do the<br>  | normalization.<br><br>Don't care about that, since the result won't be being saved.<br><br>  | Add to that a flag that indicates if the UTC time is fixed!<br><br>If the UTC time is the authoritative one, that is what is stored.<br>No need for extra flags.   Just the authoritative time - the one<br>which defines whatever it is that is being recorded.<br></blockquote><div><br></div><div>I second everything Robert Elz said here.</div><font color="#888888"><div><br></div><div> - Michael Kenniston</div><div><br></div></font></div></div></div>