On Wed, Mar 17, 2021 at 8:20 AM Thomas Munro wrote:
> *I mean, we can discuss the different "timelines" like UT, UTC, TAI
> etc, but that's getting into the weeds, the usual timeline for
> computer software outside specialist scientific purposes is UTC
> without leap seconds.
(Erm, rereading this
On Tue, Mar 30, 2021 at 11:16 AM Daniel Verite
wrote:
>
> The conversions from julian dates are not necessarily hard, but the
> I/O functions means having localized names for all days, months, eras
> of all calendars in all supported languages. If you're thinking of
> implementing this from scrat
Surafel Temesgen wrote:
> > About intervals, if there were locale-aware functions like
> > add_interval(timestamptz, interval [, locale]) returns timestamptz
> > or
> > sub_timestamp(timestamptz, timestamptz [,locale]) returns interval
> > that would use ICU to compute the results accord
Hi Daniel,
On Fri, Mar 26, 2021 at 8:51 PM Daniel Verite
wrote:
> Thomas Munro wrote:
>
> > Right, so if this is done by trying to extend Daniel Verite's icu_ext
> > extension (link given earlier) and Robert's idea of a fast-castable
> > type, I suppose you might want now()::icu_date + '
On Mon, 29 Mar 2021 at 14:33, Daniel Verite wrote:
>
> Matthias van de Meent wrote:
>
> > The results for the Japanese locale should be "0003 Reiwa" instead of
> > "0033 Heisei", as the era changed in 2019. ICU releases have since
> > implemented this and other corrections; this specific c
Matthias van de Meent wrote:
> The results for the Japanese locale should be "0003 Reiwa" instead of
> "0033 Heisei", as the era changed in 2019. ICU releases have since
> implemented this and other corrections; this specific change was
> implemented in the batched release of ICU versions
On Fri, 26 Mar 2021 at 18:51, Daniel Verite wrote:
> [...]
> -[ RECORD 2 ]--+---
> cal| japanese
> now_str| 26/mars/0033 Heisei 18:22:07.566 UTC+1
> now_parsed | 2021-03-26 18:22:07.566+01
> plus_1m| 26/avril/0033
On Sat, Mar 27, 2021 at 6:51 AM Daniel Verite wrote:
> now_str| 17/mägabit/2013 après l’Incarnation 18:22:07.566 UTC+1
Very nice!
> For instance with the ethiopic calendar, the query above displays today as
> 17/mägabit/2013 and 1 month from now as 18/miyazya/2013,
> while the correct re
Thomas Munro wrote:
> Right, so if this is done by trying to extend Daniel Verite's icu_ext
> extension (link given earlier) and Robert's idea of a fast-castable
> type, I suppose you might want now()::icu_date + '1 month'::internal
> to advance you by one Ethiopic month if you have done S
On Wed, Mar 17, 2021 at 3:39 PM Thomas Munro wrote:
> On Thu, Mar 18, 2021 at 3:48 AM Tom Lane wrote:
>
> Right, so if this is done by trying to extend Daniel Verite's icu_ext
> extension (link given earlier) and Robert's idea of a fast-castable
> type, I suppose you might want now()::icu_date +
On 3/17/21 3:48 PM, Tom Lane wrote:
> Also, the SQL spec says in so many words
> that the SQL-defined datetime types follow the Gregorian calendar.
We already don't follow the SQL spec for timestamps (and I, for one,
think we are better for it) so I don't think we should worry about that.
--
Vik
On Thu, Mar 18, 2021 at 3:48 AM Tom Lane wrote:
> Robert Haas writes:
> > It's not very obvious how to scale this kind of approach to a wide
> > variety of calendar types, and as Thomas says, it would much cooler to
> > be able to handle all of the ones that ICU knows how to support rather
> > th
Robert Haas writes:
> It's not very obvious how to scale this kind of approach to a wide
> variety of calendar types, and as Thomas says, it would much cooler to
> be able to handle all of the ones that ICU knows how to support rather
> than just one. But, the problem I see with using timestamptz
On Wed, Mar 17, 2021 at 9:54 AM Surafel Temesgen wrote:
> As you mention above whatever the calendar type is we ended up storing an
> integer that represent the date so rather than re-implementing every
> function and operation for every calendar we can use existing Gerigorian
> implementation
On Tue, Mar 16, 2021 at 12:20 PM Thomas Munro
wrote:
> On Wed, Mar 17, 2021 at 6:31 AM Surafel Temesgen
> wrote:
> > Ethiopice calendar have 13 months so it can not be stored as date and
> timestamp type and you approach seems more complicated and i suggest to
> have this feature on the purpose
On Wed, Mar 17, 2021 at 6:31 AM Surafel Temesgen wrote:
> Ethiopice calendar have 13 months so it can not be stored as date and
> timestamp type and you approach seems more complicated and i suggest to have
> this feature on the purpose of PostgreSQL popularities too not only for my
> need
I k
Hi Thomas
On Mon, Mar 15, 2021 at 2:58 PM Thomas Munro wrote:
>
> One key question here is whether you need a different date type or
> just different operations (functions, operators etc) on the existing
> types.
>
>
I am thinking of having a converter to a specific calendar after each
operation
Hi Surafel,
On Tue, Mar 16, 2021 at 3:48 AM Surafel Temesgen wrote:
> My country(Ethiopia) is one of the nations that uses different kind of
> calendar than what PostgreSQL have so we are deprived from the benefit of
> data datatype. We just uses String to store date that limits our application
Hi all,
My country(Ethiopia) is one of the nations that uses different kind of
calendar than what PostgreSQL have so we are deprived from the benefit of
data datatype. We just uses String to store date that limits our
application quality greatly. The lag became even worst once application and
syste
19 matches
Mail list logo
