Re: Locale support

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

In response to

Browse pgsql-hackers by date

  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