Bug 466820 - Incorrect daylight saving time to Brazil
Incorrect daylight saving time to Brazil
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: tzdata (Show other bugs)
9
All Linux
medium Severity high
: ---
: ---
Assigned To: Petr Machata
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-13 16:44 EDT by Fabrício Godoy
Modified: 2015-05-04 21:34 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-16 07:52:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Fabrício Godoy 2008-10-13 16:44:18 EDT
Description of problem:
Daylight saving time, in Brazil, begins October 19 and in my system is already in daylight saving time.

Version-Release number of selected component (if applicable):
Last release of tzdata (October 10, I think) in Fedora 9.

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:
Correct tzdata following final instructions on below web page:
http://www.timeanddate.com/news/time/brazil-dst-2008-2009.html

Additional info:
Should be desirable that an tzdata update should back my clock out of daylight saving time, and in October 19 back again.
Comment 1 Fabrício Godoy 2008-10-13 21:12:25 EDT
Sorry, not is a good idea back the clock incorrect adjusted by tzdata, because almost users, probably, changed clock back manually.
Comment 2 Petr Machata 2008-10-14 05:00:39 EDT
The change you refer to was introduced in tzdata-2008f, which went out to Fedora 9 stable on 2008-09-24[1].  There was another change after that, fixing Brazil DST transitions for times in future (where it collided with The Carnival before); that was tzdata-2008g, released 2008-10-09[2].  So you should be all set (but apparently you are not, for some reason).

Can you send me the output of following commands?
 - rpm -q tzdata
 - rpm -V tzdata
 - cat /etc/sysconfig/clock
   - there should be some ZONE setting in that file, e.g. ZONE=America/Sao_Paulo
     From now on, I'll refer to that zone by $TZ
 - md5sum /etc/localtime /usr/share/zoneinfo/$TZ

I'm suspecting that glibc trigger didn't update /etc/localtime, the above should either confirm or dispel that suspicion.

[1] https://admin.fedoraproject.org/updates/F9/FEDORA-2008-8317
[2] https://admin.fedoraproject.org/updates/F9/FEDORA-2008-8714
Comment 3 Fabrício Godoy 2008-10-14 21:23:34 EDT
[fabricio@localhost ~]$ rpm -q tzdata
tzdata-2008g-1.fc9.noarch
[fabricio@localhost ~]$ rpm -V tzdata
[fabricio@localhost ~]$ cat /etc/sysconfig/clock
# The ZONE parameter is only evaluated by system-config-date.
# The time zone of the system is defined by the contents of /etc/localtime.
ZONE="America/Sao Paulo"
[fabricio@localhost ~]$ md5sum /etc/localtime /usr/share/zoneinfo/America/Sao_Paulo
7613c2153980b60de4fb74f692d7c1eb  /etc/localtime
7613c2153980b60de4fb74f692d7c1eb  /usr/share/zoneinfo/America/Sao_Paulo
[fabricio@localhost ~]$
Comment 4 Petr Machata 2008-10-15 04:58:35 EDT
md5sums of your localtime and Sao_Paulo files match with md5sum on my installation.  That pretty much confirms that there was no problem during update, nor was there tampering with the files.  On my installation, zdump of Sao_Paulo shows the following:

$ /usr/sbin/zdump -v /usr/share/zoneinfo/America/Sao_Paulo | grep 2008
/usr/share/zoneinfo/America/Sao_Paulo  Sun Feb 17 01:59:59 2008 UTC = Sat Feb 16 23:59:59 2008 BRST isdst=1 gmtoff=-7200
/usr/share/zoneinfo/America/Sao_Paulo  Sun Feb 17 02:00:00 2008 UTC = Sat Feb 16 23:00:00 2008 BRT isdst=0 gmtoff=-10800
/usr/share/zoneinfo/America/Sao_Paulo  Sun Oct 19 02:59:59 2008 UTC = Sat Oct 18 23:59:59 2008 BRT isdst=0 gmtoff=-10800
/usr/share/zoneinfo/America/Sao_Paulo  Sun Oct 19 03:00:00 2008 UTC = Sun Oct 19 01:00:00 2008 BRST isdst=1 gmtoff=-7200

Which means that the transition shouldn't have occurred until Oct 19.  That it did occur can have several reasons.
 1) you didn't have your tzdata updated to the version higher than 2008e soon enough (and the rule Oct Sun>=8 had taken effect)
 2) you did have all the updates, but the hitch occured that I was trying to discover above using the md5 sums.  But you updated tzdata after that, and the hitch is no longer visible.

Whichever is the case, the bug is not on side of tzdata, we're ready for Brazil DST change a couple releases already.
Comment 5 Fabrício Godoy 2008-10-15 07:21:56 EDT
I remember that at October 10 my system was updated to tzdata-2008g and at October 12 00:00 my system entered in daylight saving time.
Comment 6 Petr Machata 2008-10-15 08:13:13 EDT
So does your computer think you are in DST right now?  You can find out like this:
$ date +%Z
If it shows BRST, you are in daylight saving period.  If it's BRT, you are not.  If it's something else, you are in a wrong zone :)

If you are in BRT, what happened between now and back when it thought you are in the DST?  Which event caused the time to become "normal" again?  I.e. what fixed the bug?

And how did you find out that you are in the DST period?  Was it because of e.g. Gnome clocks, or simply typing date into the console?  I'm asking because some applications have had their own timezone support, e.g. Java used to have DST transitions hard-coded until recently, and there might still be more cases like this.

If you are in BRST, we have a very strange situation, because your files seem to be right.  We will have to dig a bit deeper in that case.
Comment 7 Fabrício Godoy 2008-10-15 20:03:59 EDT
I don't understand:

[fabricio@localhost ~]$ date
Qua Out 15 20:57:15 BRT 2008
[fabricio@localhost ~]$ /usr/sbin/zdump -v /usr/share/zoneinfo/America/Sao_Paulo | grep 2008
/usr/share/zoneinfo/America/Sao_Paulo  Sun Feb 17 01:59:59 2008 UTC = Sat Feb 16 23:59:59 2008 BRST isdst=1 gmtoff=-7200
/usr/share/zoneinfo/America/Sao_Paulo  Sun Feb 17 02:00:00 2008 UTC = Sat Feb 16 23:00:00 2008 BRT isdst=0 gmtoff=-10800
/usr/share/zoneinfo/America/Sao_Paulo  Sun Oct 19 02:59:59 2008 UTC = Sat Oct 18 23:59:59 2008 BRT isdst=0 gmtoff=-10800
/usr/share/zoneinfo/America/Sao_Paulo  Sun Oct 19 03:00:00 2008 UTC = Sun Oct 19 01:00:00 2008 BRST isdst=1 gmtoff=-7200

I thinked that my computer is in DST period because the clock was advanced one hour. I don't know if was BRT or BRST, sorry.
Comment 8 Fabrício Godoy 2008-10-15 20:11:26 EDT
I tried to simulate same condition adjusting the clock to October 11 23:59:00 and the system not advanced 1 hour at October 12 00:00:00.
I really don't understand what was happened.
Comment 9 Petr Machata 2008-10-16 07:52:52 EDT
Neither do I.  I'm afraid it's not possible to discover what happened and why anymore.

Note You need to log in before you can comment on or make changes to this bug.