[tz] Potential problem with Sao_Paulo TZ in tzdata2019c
Paul Eggert
eggert at cs.ucla.edu
Fri Nov 1 20:49:26 UTC 2019
On 11/1/19 11:58 AM, Bryan Coleman wrote:
> I found this while working with java and noticed it after upgrading from
> adoptopenjdk version 8u222_b10 to version 8u232_b09. I believe 222
> utilizes tzdata2019a while 232 utilizes tzdata2019c. I understand that
> there are many things that could cause the issue from the code running
> in java down the stack to the tzdata; however, believe tzdata is the
> most likely culprit.
I don't see a problem on the tzdb side. It shows just one transition in
February 2014, on 2014-02-15 at 02:00 UTC, from -02 to -03:
$ zdump -V -c 2014,2015 America/Sao_Paulo
America/Sao_Paulo Sun Feb 16 01:59:59 2014 UT = Sat Feb 15 23:59:59
2014 -02 isdst=1 gmtoff=-7200
America/Sao_Paulo Sun Feb 16 02:00:00 2014 UT = Sat Feb 15 23:00:00
2014 -03 isdst=0 gmtoff=-10800
America/Sao_Paulo Sun Oct 19 02:59:59 2014 UT = Sat Oct 18 23:59:59
2014 -03 isdst=0 gmtoff=-10800
America/Sao_Paulo Sun Oct 19 03:00:00 2014 UT = Sun Oct 19 01:00:00
2014 -02 isdst=1 gmtoff=-7200
> Any thoughts/ideas of how to track this down?
I suggest looking on the adoptopenjdk side. The reference output lines
labeled jdk 8.222_b10 and jdk 8.232_b09 are both incorrect, as there
should be just one transition in February 2014.
> Reference Output:
>
> jdk 8.222_b10
> 2014-02-15 23:59:59 BRST: 1392515999000
> 2014-02-15 23:00:00 BRST: 1392512400000
> 2014-02-15 23:00:00 BRT : 1392516000000
> 2014-02-16 00:00:00 BRST: 1392516000000
> 2014-02-16 00:00:00 BRT : 1392519600000
>
> jdk 8.232_b09
> 2014-02-15 23:59:59 BRST: 1392519599000
> 2014-02-15 23:00:00 BRST: 1392516000000
> 2014-02-15 23:00:00 BRT : 1392516000000
> 2014-02-16 00:00:00 BRST: 1392519600000
> 2014-02-16 00:00:00 BRT : 1392519600000
More information about the tz
mailing list