As long as we're considering decreasing the historical fidelity of assorted pre-1970 timestamps, I'd like to make a modest suggestion: forget all the "LMT" offsets for years before standardized timezones prevailed, and just assume that the oldest documented standard-time offset in each zone goes back indefinitely far. The reason I suggest this is that we regularly get questions on the Postgres lists from novices who are confused by this behavior (pardon the SQL-isms): postgres=# set timezone = 'UTC'; SET postgres=# select timestamptz '1884-01-01 12:00 America/New_York'; timestamptz ------------------------ 1884-01-01 17:00:00+00 (1 row) This is, of course, saying that noon in New York translates to 1700 UT ... postgres=# select timestamptz '1883-01-01 12:00 America/New_York'; timestamptz ------------------------ 1883-01-01 16:56:02+00 (1 row) ... uh, what? The novices are definitely not expecting that, and they don't find it helpful. We have to explain it away as "that's what tzdb says", but it's still unhelpful. It's even sillier when you consider postgres=# select timestamptz '1752-09-10 12:00 America/New_York'; timestamptz ------------------------ 1752-09-10 16:56:02+00 (1 row) as calendar experts will recall that no such date was recognized in the British colonies. So although it's debatable whether we even know what day it is, for sure we know the UTC offset to the second. So basically, if we're willing to use proleptic Gregorian calendar for years before anyone was actually using that calendar, it's not very clear why we shouldn't use proleptic standard time too. I'd be willing to consider implementing that behavior in Postgres if I could tell (a) that a given offset is LMT not standardized time and (b) what the zone's oldest standardized offset is. But AFAICT that's not possible without mucking with the behavior of localtime.c, which I'd much prefer not to. So ... how about just dropping this oddity from the source data? regards, tom lane
On Sat 2021-05-22T16:56:53-0400 Tom Lane via tz hath writ:
The reason I suggest this is that we regularly get questions on the Postgres lists from novices who are confused by this behavior (pardon the SQL-isms):
postgres=# set timezone = 'UTC'; SET postgres=# select timestamptz '1884-01-01 12:00 America/New_York'; timestamptz ------------------------ 1884-01-01 17:00:00+00 (1 row)
This is, of course, saying that noon in New York translates to 1700 UT ...
postgres=# select timestamptz '1883-01-01 12:00 America/New_York'; timestamptz ------------------------ 1883-01-01 16:56:02+00 (1 row)
... uh, what? The novices are definitely not expecting that,
and they don't find it helpful. We have to explain it away as "that's what tzdb says", but it's still unhelpful.
It serves to remind folks that there is a point in time before which the question they think they asked has no meaning; that if they want precise time before then they will have to decide what question they are trying to answer. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m
Tom Lane via tz <tz@iana.org> wrote on Sat, 22 May 2021 at 16:56:53 EDT in <282540.1621717013@sss.pgh.pa.us>:
As long as we're considering decreasing the historical fidelity of assorted pre-1970 timestamps, I'd like to make a modest suggestion: forget all the "LMT" offsets for years before
It seems to me tha tthese kinds of changes are not a good idea. They amount to unnecessary churn for minimal benefit. For one thing, it means any extant (pre-1970 or whatever) affected timestamps in these zones will randomly shift, and that's not something we really want to do. There's not a lot of this, presumably, but it's nonzero. -- jhawk@alum.mit.edu John Hawkinson
John Hawkinson via tz <tz@iana.org> writes:
Tom Lane via tz <tz@iana.org> wrote on Sat, 22 May 2021 at 16:56:53 EDT in <282540.1621717013@sss.pgh.pa.us>:
As long as we're considering decreasing the historical fidelity of assorted pre-1970 timestamps, I'd like to make a modest suggestion: forget all the "LMT" offsets for years before
It seems to me tha tthese kinds of changes are not a good idea. They amount to unnecessary churn for minimal benefit. For one thing, it means any extant (pre-1970 or whatever) affected timestamps in these zones will randomly shift, and that's not something we really want to do. There's not a lot of this, presumably, but it's nonzero.
Agreed, but then why are the changes Paul is proposing okay? regards, tom lane
On 5/22/21 2:41 PM, Tom Lane via tz wrote:
why are the changes Paul is proposing okay?
The goal is to simplify long-term maintenance in exchange for trivial short-term pain. Over the years I've spent far too much time maintaining irrelevant info and getting bogged down with the resulting politics. Had this change been installed a while ago, for example, we would have saved significant time by not worrying about timekeeping in Vietnam before 1970. No doubt there will be similar issues in the future, and the less irrelevant data we have now, the better off we'll be in the future.
On 2021-05-23 04:56:53 (+0800), Tom Lane via tz wrote:
As long as we're considering decreasing the historical fidelity of assorted pre-1970 timestamps, I'd like to make a modest suggestion: forget all the "LMT" offsets for years before standardized timezones prevailed, and just assume that the oldest documented standard-time offset in each zone goes back indefinitely far.
I would support this, provided we keep the LMT offsets in backzone so that (more or less) casual users wouldn't notice the difference. Unfortunately, this would probably mean that Postgres wouldn't notice the difference either. I'm sure there are (obscure) applications that care about LMT. Though I can't actually imagine what any of them might be. (And I'm not sure I really want to imagine them.)
It's even sillier when you consider
postgres=# select timestamptz '1752-09-10 12:00 America/New_York'; timestamptz ------------------------ 1752-09-10 16:56:02+00 (1 row)
as calendar experts will recall that no such date was recognized in the British colonies. So although it's debatable whether we even know what day it is, for sure we know the UTC offset to the second.
Arguably, the precise UTC offset is a bit of a guess too. I would consider this specific example to fall into the "ask a silly question, get a silly answer" territory. Another fun one for this category is e.g. 1800-01-01 12:00 Europe/Paris. (I have unfortunately once in my past had to deal with precisely such oddities. I live a cursed life.)
So basically, if we're willing to use proleptic Gregorian calendar for years before anyone was actually using that calendar, it's not very clear why we shouldn't use proleptic standard time too.
This is a good point. Particularly since LMT is only "correct" for very narrow regions within any given timezone.
I'd be willing to consider implementing that behavior in Postgres if I could tell (a) that a given offset is LMT not standardized time and (b) what the zone's oldest standardized offset is. But AFAICT that's not possible without mucking with the behavior of localtime.c, which I'd much prefer not to.
So ... how about just dropping this oddity from the source data?
Since, unlike Paul's other changes, the LMT offsets don't pose any kind of maintenance burden, I'm lukewarm about this suggestion. It would be a lot of repo churn for not even an invisible benefit. Having said that, I'm not opposed to the idea. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
On Sun 2021-05-23T10:54:16+0800 Philip Paeps via tz hath writ:
This is a good point. Particularly since LMT is only "correct" for very narrow regions within any given timezone.
In general LMT is not even correct for the city at the given location. Prior to 1834 the Nautical Almanac tabulated Greenwich Apparent Time, not Greenwich Mean Time. In the US insurers during the 19th century wrote policies which specified the expiration at noon on a particular date because it was reasonably likely that witnesses could testify as to whether the fire started while the sun was on the east side of buildings or the west side of buildings. For the purposes of the insurance legal time was local apparent solar time, not local mean solar time. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m
Steve Allen via tz <tz@iana.org> writes:
On Sun 2021-05-23T10:54:16+0800 Philip Paeps via tz hath writ:
This is a good point. Particularly since LMT is only "correct" for very narrow regions within any given timezone.
In general LMT is not even correct for the city at the given location.
Yeah, this. The entire premise of tzdb's zones is that the same time is/was observed over the whole area of the zone. Even granting that the time in New York City back in 1883 was exactly GMT-4:56:02, surely that's complete fiction for most of the zone? We're not helping anybody by specifying many digits of fictional precision. Having said that, I do buy John Hawkinson's point that fooling around with tzdb's data for past timestamps is a bad idea. But that should apply equally to Paul's proposal to drop the existing data for times later than the LMT era. regards, tom lane
On 2021-05-22 21:38, Steve Allen via tz wrote:
On Sun 2021-05-23T10:54:16+0800 Philip Paeps via tz hath writ:
This is a good point. Particularly since LMT is only "correct" for very narrow regions within any given timezone.
In general LMT is not even correct for the city at the given location.
Prior to 1834 the Nautical Almanac tabulated Greenwich Apparent Time, not Greenwich Mean Time.
As illustrated by Greenwich relative to London it was often the local university, naval academy, other closest observatory, or transit telescope owner who defined the latitude and offset of local solar time, and as stated, whether apparent or mean time was calculated, distributed, and used locally.
In the US insurers during the 19th century wrote policies which specified the expiration at noon on a particular date because it was reasonably likely that witnesses could testify as to whether the fire started while the sun was on the east side of buildings or the west side of buildings. For the purposes of the insurance legal time was local apparent solar time, not local mean solar time.
From the legal viewpoint in the English common law based legal world, which is most of the Commonwealth of Nations and former colonies including the USA, mean solar time represented by UT and some offset(s) still applies, due to pre-atomic precedents, regardless of IAU, ISO, or ITU opinions about ephemerides, atomic physics, or radio signals. If tested, I would expect the current definition of the second may have no legal basis in those jurisdictions, and it would be interesting to see if a case could be made on the technicality that times commonly used and often relied upon may not be legally valid. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
Brian Inglis via tz said:
From the legal viewpoint in the English common law based legal world, which is most of the Commonwealth of Nations and former colonies including the USA, mean solar time represented by UT and some offset(s) still applies, due to pre-atomic precedents, regardless of IAU, ISO, or ITU opinions about ephemerides, atomic physics, or radio signals. If tested, I would expect the current definition of the second may have no legal basis in those jurisdictions, and it would be interesting to see if a case could be made on the technicality that times commonly used and often relied upon may not be legally valid.
I can't speak for anywhere else, but if it became a significant point in a case, I would expect an English judge to rule that "Greenwich mean time" has now come to mean UTC. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On 2021-05-23 16:33, Clive D.W. Feather wrote:
Brian Inglis via tz said:
From the legal viewpoint in the English common law based legal world, which is most of the Commonwealth of Nations and former colonies including the USA, mean solar time represented by UT and some offset(s) still applies, due to pre-atomic precedents, regardless of IAU, ISO, or ITU opinions about ephemerides, atomic physics, or radio signals. If tested, I would expect the current definition of the second may have no legal basis in those jurisdictions, and it would be interesting to see if a case could be made on the technicality that times commonly used and often relied upon may not be legally valid.
I can't speak for anywhere else, but if it became a significant point in a case, I would expect an English judge to rule that "Greenwich mean time" has now come to mean UTC.
I think rather that UTC (as it is currently defined) could be ruled a legally valid approximation to mean solar time at the standard meridian, which is what the precedents deal with. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
Philip Paeps via tz said:
As long as we're considering decreasing the historical fidelity of assorted pre-1970 timestamps, I'd like to make a modest suggestion: forget all the "LMT" offsets for years before standardized timezones prevailed, and just assume that the oldest documented standard-time offset in each zone goes back indefinitely far.
I would support this, provided we keep the LMT offsets in backzone so that (more or less) casual users wouldn't notice the difference.
I would actually say that, if we're going to do something like that, there should be a way to put a "not valid before" marker into the zone data and have the functions return either an error or a clearly nonsense answer. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On Sun 2021-05-23T22:43:46+0100 Clive D.W. Feather via tz hath writ:
I would actually say that, if we're going to do something like that, there should be a way to put a "not valid before" marker into the zone data and have the functions return either an error or a clearly nonsense answer.
My impression is that the answers provided by creating such an interface would be indistinguishable from the LMT of Kew Observatory for London, and the city longitudes for everything else. Those are already akin to nonsense or a declaration of invalidity. The disruption caused by creating such an interface and the maintenance of the cutoff dates would be two reasons to say that what LMT values are in existence now already implements this idea. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m
Steve Allen via tz said:
On Sun 2021-05-23T22:43:46+0100 Clive D.W. Feather via tz hath writ:
I would actually say that, if we're going to do something like that, there should be a way to put a "not valid before" marker into the zone data and have the functions return either an error or a clearly nonsense answer.
My impression is that the answers provided by creating such an interface would be indistinguishable from the LMT of Kew Observatory for London, and the city longitudes for everything else. Those are already akin to nonsense or a declaration of invalidity.
Only to someone who knows what the right answer would be. I haven't looked at the interfaces in question, but if it can't return a failure code, I was thinking more of always returning 0000-01-01T00:00:00 irrespective of the input, or something like that. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On May 23, 2021, at 3:29 PM, Clive D.W. Feather via tz <tz@iana.org> wrote:
I haven't looked at the interfaces in question, but if it can't return a failure code,
localtime() can return NULL according to C99 and according to the Single UNIX Specification, and *does* return NULL for all times prior to the Epoch on a certain (non-UN*X) platform from Redmond, Washington.
On Sun, 23 May 2021 at 18:10, Steve Allen via tz <tz@iana.org> wrote:
On Sun 2021-05-23T22:43:46+0100 Clive D.W. Feather via tz hath writ:
I would actually say that, if we're going to do something like that, there should be a way to put a "not valid before" marker into the zone data and have the functions return either an error or a clearly nonsense answer.
The disruption caused by creating such an interface and the maintenance of the cutoff dates would be two reasons to say that what LMT values are in existence now already implements this idea.
+1 -- Tim Parenti
On 5/23/21 2:43 PM, Clive D.W. Feather via tz wrote:
there should be a way to put a "not valid before" marker into the zone data and have the functions return either an error or a clearly nonsense answer.
RFC 8536 section 5.1 says that client code can use the first transition time as a "not valid before" marker - that is, client code can return an error before the first transition. However, it's common for clients to assume that all timestamps can be converted - something that is true on older or smaller POSIX hosts with 32-bit time_t and 32-bit int - and so tzcode (and all POSIXish client code that I know about) does convert timestamps before the first transition. And when doing that conversion, using the LMT offset typically yields a more-accurate answer for the affected area than using a 0 offset would. I doubt whether we could change this behavior in client code now, without causing more trouble than it'd cure.
On May 23, 2021, at 7:59 PM, Paul Eggert via tz <tz@iana.org> wrote:
However, it's common for clients to assume that all timestamps can be converted - something that is true on older or smaller POSIX hosts with 32-bit time_t and 32-bit int
...and much of that client code may never be ported to Windows, so the problems with that assumption on Windows won't show up and force the code to stop making that assumption.
participants (9)
-
Brian Inglis -
Clive D.W. Feather -
Guy Harris -
John Hawkinson -
Paul Eggert -
Philip Paeps -
Steve Allen -
Tim Parenti -
Tom Lane