Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> I agree we don't want a simplistic change that would only change the
> rule from Gregorian to Julian without much other thinking; but suppose
> Bruce H was able to come up with a well reasoned design to cover all
> interesting cases, would we consider accepting a patch that changed the
> behavior?
Meh. Using Julian calendar from circa 50 BC to 1582 is the "right thing"
in some abstract sense, but:
1. What ya gonna do before 50 BC? If your argument against proleptic
Gregorian is that it doesn't represent what people actually did, then
replacing it with proleptic Julian is no better.
2. There's that two weeks or so that completely disappeared in the switch.
Those are dates we'd no longer accept (or at least if we did, it's none
too clear what we'd do with them). This creates a dump/reload hazard.
3. Between #2 and the altered frequency of leap years, stored dates
before 1582 would change meaning rather substantially, so that the
results of pg_upgrade would differ from a dump/reload.
4. We'd be adding a substantial amount of complexity, cycles, and possibly
bugs to all datetime operations, in service of what is evidently a tiny
minority requirement (and one that not only lacks support in the SQL
standard, but is arguably contrary to the express wording of same).
5. A side issue that's probably pretty relevant for the OP's application
is that not every country adopted the Gregorian calendar at the same time.
Really if he wants any data integrity he's going to need to store an
explicit indication of whether a date is in Julian or Gregorian calendar.
(In a world of infinite manpower you could imagine extending the zic
database to provide information about which calendar was used when in
every region, but I don't see us going there.)
So the risk/reward/backwards-compatibility tradeoff just doesn't look
very good from here.
I think the OP's best bet is to store old dates as text, or perhaps
integers, with some CHECK constraints to make whatever validity checks
he deems appropriate.
> I would also go as far as suggesting that a different data
> type might be a useful direction to consider.
Yeah, an extension data type is also a possibility, but it'd be a
significant amount of work.
regards, tom lane