Changes in daylight saving rules in Brazil

Dear IANA Team, My name is Alexandre Dias and I'm a Data Scientist at a Brazilian Startup called Looqbox. As an R programmer and knowing that R uses the international standard IANA time zone rules. I would like to inform that the current Brazilian government changed daylight saving rules for "America/Sao_Paulo" timezone. This changes occurred this year and many devices are operating under the wrong hour of the day. Usually, at this time of the year we had to advance our clock by one hour going from -03 GMT to -02. However, as I said, this is no longer the rules and the clocks must remain -03 GMT. Following there is a print of this phenomenon showing that R is display and returning the wrong time for my timezone: [image: image.png] <https://files.slack.com/files-pri/T0NA05E3Y-FQ4LFH6CV/image.png> The correct output should be "2019-11-04 13:25:27 -03". Given the problems that may arise from this kind of behavior, I kindly ask you to apply the changes I informed above as soon as possible. Sincerely yours, Alexandre Henrique Soares Dias Data Scientist at Looqbox

The recent changes to Brazil were published as part of tzdb 2019b, released 2019-07-01. Evidently these changes have not propagated to your system, so you'll need to update it (preferably to 2019c, the current release). The details for this depend on your platform; as an R user, you might consult <https://svn.r-project.org/R/trunk/src/extra/tzone/Notes> to get started.

On 2019-11-04 10:20, Alexandre Henrique Soares Dias wrote:
My name is Alexandre Dias and I'm a Data Scientist at a Brazilian Startup called Looqbox. As an R programmer and knowing that R uses the international standard IANA time zone rules. I would like to inform that the current Brazilian government changed daylight saving rules for "America/Sao_Paulo" timezone. This changes occurred this year and many devices are operating under the wrong hour of the day.
Usually, at this time of the year we had to advance our clock by one hour going from -03 GMT to -02. However, as I said, this is no longer the rules and the clocks must remain -03 GMT. Following there is a print of this phenomenon showing that R is display and returning the wrong time for my timezone:
image.png <https://files.slack.com/files-pri/T0NA05E3Y-FQ4LFH6CV/image.png>
The correct output should be "2019-11-04 13:25:27 -03".
Given the problems that may arise from this kind of behavior, I kindly ask you to apply the changes I informed above as soon as possible.
If time zone or DST changes have been announced publicly in advance and are common knowledge in your region, someone will have reported it to the list, and the data will have been updated. Exceptions are when governments provide no advance public notice of changes (Turkey!), only inform major tourist and/or airline organizations, or provide vague or imprecise details in announcements, and are shocked when systems show incorrect time for weeks afterwards, as IT support wait for official updates. When these updates are picked up by your systems vendors and made available for your systems, depends on their promptness in picking up and progressing the updates through their processes, but mainly on how promptly your local IT support apply those changes to your systems once available, and they should be your first point of contact if there are time discrepancies on your systems. If you are your own IT support, you are responsible for finding out how to apply such changes to your systems, and how to find out when they are available. Some system distributions may be poorly supported and you may have to prompt them to be more timely in applying and propagating time zone and DST updates. Some smartphone vendors and telcos are slower providing updates for older and/or lower volume handsets and you should complain to your telco to be more timely providing time zone and DST updates and/or announcing workarounds. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.
participants (3)
-
Alexandre Henrique Soares Dias
-
Brian Inglis
-
Paul Eggert