[tz] So, about those LMT offsets

[Tom Lane]

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