Time-zone database issues

Stephen Colebourne scolebourne at joda.org
Tue Oct 23 09:57:25 UTC 2018

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

Use of these methods is incredibly rare - it is a very specialist API
- and is supposed to match the data in tzdb. In addition, the most
important method of the class is createTransition(int) which is
unaffected by the changes. So the compatibility risk here really is
absolutely tiny.


More information about the core-libs-dev mailing list