Bug 506941 (Bangladesh_DST) - Bangladesh introduces DST 20th Jun
Summary: Bangladesh introduces DST 20th Jun
Alias: Bangladesh_DST
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Andreas Schwab
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2009-06-19 12:18 UTC by Angel
Modified: 2009-09-22 08:28 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-09-22 08:28:46 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Launchpad 383444 None None None Never
Red Hat Bugzilla 503832 None None None Never

Description Angel 2009-06-19 12:18:51 UTC
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.

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 16:14:12 UTC
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
(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


$ 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

Comment 2 Andreas Schwab 2009-06-22 16:18:47 UTC
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 16:52:38 UTC
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 17:18:11 UTC
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 12:29:10 UTC
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 08:28:46 UTC
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.