From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
---|---|
To: | Yonatan Misgan <yonamis(at)dtu(dot)edu(dot)et>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Locale support |
Date: | 2019-08-08 14:22:45 |
Message-ID: | b20d8da2-887f-4f8e-271d-012b9cc6264f@anastigmatix.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 8/8/19 9:29 AM, Yonatan Misgan wrote:
> From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
>> Perl, Python etc. If I were you I think I'd experiment with a
>> prototype implementation using PL/Perl, PL/Python etc (a way to
As a bit of subtlety that might matter, the internal representation
in PostgreSQL, as in ISO 8601, applies the Gregorian calendar
'proleptically', that is, forever into the future, and forever into
the past, before it was even invented or in use anywhere.
That matches the documented behavior of the standard 'datetime'
class included with Python (though in Python you need an add-on
module to support time zones).
In Perl, an add-on module may be required.
(In Java, the classes in the java.time package match the PostgreSQL /
ISO 8601 behavior, while the classes in the java.sql package do not.)
The effects of any mismatch are most likely to show up in dates
earlier than 15 October 1582 Gregorian.
This was freshly on my mind from a recent thread over here[1].
Regards,
-Chap
[1]
https://www.postgresql.org/message-id/5D3AF944.6020900%40anastigmatix.net
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2019-08-08 14:27:25 | clean up obsolete initdb locale handling |
Previous Message | Rafia Sabih | 2019-08-08 13:42:33 | Re: Resume vacuum and autovacuum from interruption and cancellation |