Time-zone database issues

Florian Weimer fweimer at redhat.com
Tue Oct 23 10:47:25 UTC 2018

* Stephen Colebourne:

> On Tue, 23 Oct 2018 at 09:44, Florian Weimer <fweimer at redhat.com> wrote:
>> * Stephen Colebourne:
>> > No, the day-of-month and day-of-week would remain the same, as the
>> > time is relative to those dates.
>> My expectation is that the values returned by the other methods would
>> change for a getLocalTime() that provides a normalized return value
>> because the transition rule in normalized time is different (i.e., last
>> Saturday in a month turns into something else).
> As mentioned in the original mail, it is not always possible to
> normalize the values back to sane values. Trying to do so would result
> in a worse outcome than the proposed change (more deprecations and
> more chance of users hitting compatibility problems).
> Current response (until tzdb made their recent change):
> - getDayOfWeek() = Sun
> - getLocalTime() = 01:00
> Proposed response:
> - getDayOfWeek() = Sat
> - getLocalTime() = 01:00 (deprecated)
> - getLocalTimeDuration() = 25:00

Hmm.  I'm no longer sure if normalization is always possible.  If the
rule says, “last Saturady in the month at 25:00”, there is no normalized
equivalent because every normalized rule can only express dates that
always fall into the same month, as far as I can see.

If this is correct, I think offering normalized and non-normalized
interfaces is futile.

Does it even make sense to expose this level of detail?  Many transition
rules cannot be expressed in terms of the Gregorian calendar anyway.


More information about the core-libs-dev mailing list