Bug 506941 - (Bangladesh_DST) Bangladesh introduces DST 20th Jun
Bangladesh introduces DST 20th Jun
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Andreas Schwab
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-19 08:18 EDT by Angel
Modified: 2009-09-22 04:28 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-22 04:28:46 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)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 503832 None None None Never
Launchpad 383444 None None None Never

  None (edit)
Description Angel 2009-06-19 08:18:51 EDT
Binary package hint: tzdata

Bangladesh introduces DST for the first time, setting the clocks head for an hour from 11 PM, June 19, 2009.

Timezone should therefor be changed to GMT +7 from current GMT +6 for Asia/Dhaka from above mentioned date.

It is however undecided how long this will be in effect, but estimated to be till September 30, 2009, just before the winter.

Reference:
Wikipedia: http://tr.im/nmHn
The Daily Star: http://tr.im/nmH9
AHN: http://tr.im/nmHu
Asian Tribune: http://tr.im/nmGS

SRU test case:
$ LANG= TZ=Asia/Dhaka date
Thu Jun 18 20:17:16 BDT 2009
$ LANG= TZ=Asia/Dhaka date -d "next week"
Thu Jun 25 21:17:10 BDST 2009
Comment 1 Petr Machata 2009-06-19 12:14:12 EDT
I pushed the update for that that should be already in the repository (2009i).  Fix for that update that pinpoints the transition to correct time (the previous one was an estimate) is now pending, if not already pushed (2009j).

However, I smell something fishy here on F 10:

$ rpm -q tzdata
tzdata-2009j-1.fc10.noarch
(That's hand-installed package from koji.)

$ LANG= TZ=Asia/Dhaka date -d "6/19/2009 15:00 UTC"
Fri Jun 19 21:00:00 BDT 2009
$ LANG= TZ=Asia/Dhaka date -d "6/20/2009 15:00 UTC"
Sat Jun 20 21:00:00 BDST 2009

Also:

$ zdump -v Asia/Dhaka | grep 2009
Asia/Dhaka  Fri Jun 19 16:59:59 2009 UTC = Fri Jun 19 22:59:59 2009 BDT isdst=0 gmtoff=21600
Asia/Dhaka  Fri Jun 19 17:00:00 2009 UTC = Fri Jun 19 23:00:00 2009 BDST isdst=0 gmtoff=21600

So /some/ sort of change is there in the data, as witnessed by "BDST" appearing instead of "BDT".  But the change to time zone fails to propagate.  I have a hunch that glibc bases its parsing code on routines distributed with tzdata, and so it's not a huge surprise that both of them report consistently the same thing (isdst==0, same gmtoff in both cases).

Yet my tzdiff code (I've been meaning to make that public for last six months, but never actually got around to.  I'm going to fedorahosted right after I finish this) shows exactly the difference that it should:

$ proj/tzdiff/zidiff.py {fedora/tzdata/devel/noarch/usr-2009h-1,/usr}/share/zoneinfo/Asia/Dhaka
Introduced BDST (UTC+7, dst) 19th Jun 2009 17:00:00: 

Even the screwed first guess is reported correctly:

$ proj/tzdiff/zidiff.py {fedora/tzdata/devel/noarch/usr-2009i-1,/usr}/share/zoneinfo/Asia/Dhaka
Moved BDST (UTC+7, dst) from 19th Jun 2009 18:00:00 to 17:00:00: 

That independent code sees the data right gives me some confidence in concluding that the data is in fact there, but glibc somehow fails to parse them.  Or otherwise that I'm missing something.  I'm assigning over to glibc.

Just tried the "date" thing on Rawhide, and got the same result.

# rpm -q glibc
glibc-2.10.1-2.x86_64
glibc-2.10.1-2.i686
Comment 2 Andreas Schwab 2009-06-22 12:18:47 EDT
I think this is a bug in zic.  The timezone file claims that BDST-6 is the POSIX TZ string corresponding to the situation after the last transition, when in fact no such string can be formed (since the timezone is continuously in DST).
Comment 3 Petr Machata 2009-06-22 12:52:38 EDT
Right.  I didn't notice the presence of the TZ string (I misread what 'newline-enclosed' in the spec meant).  So the glibc parsing is correct -- it applies BDST-6 after the last transition, which is just the transition that was supposed to move the zone permanently in BDST-7.  The bug indeed seems to be in zic.
Comment 4 Andreas Schwab 2009-06-22 13:18:11 EDT
But there is also a bug in the tzfile parser, it mishandles the case when the TZ string is empty (tries to use it anyway).
Comment 5 Andreas Schwab 2009-06-26 08:29:10 EDT
I have send a patch for zic to the tz list, see <http://permalink.gmane.org/gmane.comp.time.tz/2791>.
Comment 6 Andreas Schwab 2009-09-22 04:28:46 EDT
Part of tzdata2009k now, and parser fixed in 2.10.90-1.

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