On Mon, 29 Mar 2021 at 14:33, Daniel Verite <daniel@manitou-mail.org> 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 change was
> > implemented in the batched release of ICU versions on 2019-04-12.
>
> Right. I've run this test on an Ubuntu 18.04 desktop which comes with
> libicu60 . The current version for my system is 60.2-3ubuntu3.1.
> Ubuntu maintainers did not pick up the change of the new Japanese era.
> As a guess, it's because it's not a security fix.
> This contrasts with the baseline maintainers, who did an
> exceptional effort to backpatch this down to ICU 53
> (exceptional in the sense that they don't do that for bugfixes).
>
> >> 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 result is probably 17/miyazya/2013 (?)
>
> > Seeing the results for Japanese locale, you might want to update your
> > ICU library, which could fix this potential inconsistency.
>
> I agree it's always best to have the latest ICU version, but in the
> context of Postgres, we have to work with the versions that are
> typically installed on users systems. People who have pre-2019
> versions will simply be stuck with the previous Japanese era.
>
> Anyway, for the specific problem that the interval datatype cannot be
> used seamlessly across all calendars, it's essentially about how days
> are mapped into calendars, and it's unrelated to ICU updates AFAIU.
Ah, yes, I only glanced over the supplied query and misunderstood it
due to not taking enough time. I understood it as 'use icu locale info
to add 1 month to the current date', which would use ICU knowledge
about months in the locale and would be consistent with the question
mark, instead of 'use icu to interpret the result of adding one
non-icu-locale-dependent month to the current non-icu-locale-dependent
date'. If it were the former, my response would have made more sense,
but it doesn't in this case. So, sorry for the noise.
> 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 according to the locale,
> wouldn't it be good enough?
I agree, that should fix the issues at hand / grant a workable path
for locale-aware timestamp manipulation.
With regards,
Matthias van de Meent
