<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
<style>
div.markdown { white-space: normal; }
body { font-family: sans-serif; }
h1 { font-size: 1.4em; }
h2 { font-size: 1.2em; }
h3 { font-size: 1.1em; }
blockquote { margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777; }
blockquote blockquote { border-left-color: #999999; color: #999999; }
blockquote blockquote blockquote { border-left-color: #BBBBBB; color: #BBBBBB; }
blockquote a { color: #777777; }
blockquote blockquote a { color: #999999; }
blockquote blockquote blockquote a { color: #BBBBBB; }
math[display="inline"] > mrow { padding:5px; }
div.footnotes li p { margin: 0.2em 0; }
</style>
</head>
<body>
<div class="markdown">
<p dir="auto">On 2021-05-23 04:56:53 (+0800), Tom Lane via tz wrote:</p>
<blockquote>
<p dir="auto">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.</p>
</blockquote>
<p dir="auto">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.)</p>
<blockquote>
<p dir="auto">It's even sillier when you consider</p>
<h2>postgres=# select timestamptz '1752-09-10 12:00 America/New_York';<br />
timestamptz</h2>
<p dir="auto">1752-09-10 16:56:02+00<br />
(1 row)</p>
<p dir="auto">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.</p>
</blockquote>
<p dir="auto">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.</p>
<p dir="auto">(I have unfortunately once in my past had to deal with precisely such oddities. I live a cursed life.)</p>
<blockquote>
<p dir="auto">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.</p>
</blockquote>
<p dir="auto">This is a good point. Particularly since LMT is only "correct" for very narrow regions within any given timezone.</p>
<blockquote>
<p dir="auto">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.</p>
<p dir="auto">So ... how about just dropping this oddity from the source data?</p>
</blockquote>
<p dir="auto">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.</p>
<p dir="auto">Philip</p>
<p dir="auto">--<br />
Philip Paeps<br />
Senior Reality Engineer<br />
Alternative Enterprises</p>
</div>
</body>
</html>