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
18 matches
Mail list logo
