You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following are some of the values which demonstrate the issue:
#defineTZ_America_Sao_PauloPSTR("<-03>3") // Offset by +03:00 instead of -03:00
#defineTZ_Africa_CasablancaPSTR("<+01>-1") // Offset by -01:00 instead of +01:00
#defineTZ_America_AsuncionPSTR("<-04>4<-03>,M10.1.0/0,M3.4.0/0") // Offset by +4:00 instead of -03:00
This pattern appears consistent for all time zones which are defined in this format.
By contrast the following (also taken from TZ.h) do not exhibit this issue:
#defineTZ_America_Los_AngelesPSTR("PST8PDT,M3.2.0,M11.1.0") // Offset by -08:00
#defineTZ_Europe_RomePSTR("CET-1CEST,M3.5.0,M10.5.0/3") // Offset by +01:00
#defineTZ_Europe_KaliningradPSTR("EET-2") // Offset by +02:00
All of the examples above were tested today @ ~1604351488 unix timestamp.
Thanks for the report and MCVE.
This is reproducible.
I don't think it could be on newlib but we are using their API and we make no difference from working TZ and Sao Paulo.
I have so far no idea where it comes from.
Undoes the change in esp8266#7699 and fixedesp8266#7690 root cause.
Newlib did not support timezone names of the form "<[+-]?[0-9]+>" and
would parse the offset using the <name>.
Fix newlib tzset parser with
earlephilhower/newlib-xtensa#14
and undo the UNK changes used as an expedient workaround.
Undoes the change in #7699 and fixed#7690 root cause.
Newlib did not support timezone names of the form "<[+-]?[0-9]+>" and
would parse the offset using the <name>.
Fix newlib tzset parser with
earlephilhower/newlib-xtensa#14earlephilhower/newlib-xtensa#15
and undo the UNK changes used as an expedient workaround.
Basic Infos
Platform
Settings in IDE
Problem Description
It looks as if some POSIX time zone strings may be being interpreted incorrectly when configured using:
or
The following examples have been taken from TZ.h:
The following are some of the values which demonstrate the issue:
This pattern appears consistent for all time zones which are defined in this format.
By contrast the following (also taken from TZ.h) do not exhibit this issue:
All of the examples above were tested today @ ~1604351488 unix timestamp.
MCVE Sketch
Debug Messages
One example, when using TZ_America_Sao_Paulo, local time should be offset -03:00, instead it is offset +03:00:
The text was updated successfully, but these errors were encountered: