[tz] So, about those LMT offsets

[Philip Paeps]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20210523/00bdf9ff/attachment-0001.html>