Bug 6481 – Buenos Aires, Argentina time off by 1 hour

Bug 6481 - (int-149359) Buenos Aires, Argentina time off by 1 hour

(int-149359)
Summary:	Buenos Aires, Argentina time off by 1 hour

Status:	RESOLVED FIXED

Product:	Utilities
Component:	Clock
Version:	5.0/(2.2009.51-1)
Platform:	All Linux

Importance:	Low normal with 1 vote (vote)
Target Milestone:	5.0/(10.2010.19-1)
Assigned To:	unassigned
QA Contact:	core-general-bugs

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree

Reported:	2009-12-01 20:57 UTC by Jeff Moe
Modified:	2010-03-15 20:57 UTC (History)
CC List:	1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

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

Description Jeff Moe (reporter) 2009-12-01 20:57:16 UTC

SOFTWARE VERSION:
Maemo 5
1.2009.42-11.002

EXACT STEPS LEADING TO PROBLEM: 
1. Tap Clock
2. Add New World Clock for Buenos Aires, Argentina
3. Look at time it says it is.

EXPECTED OUTCOME:
The correct time for Buenos Aires, Argentina.

ACTUAL OUTCOME:
The time is off by one hour. The system thinks Buenos Aires is GMT -2, when it
really is GMT -3.

REPRODUCIBILITY:
Always.


OTHER COMMENTS:
The time was *supposed* to change on Sunday October 18th, 2009. It didn't
because the Argentina government, with zero foresight, decided against it *TWO
DAYS BEFORE* on Friday October 16th, 2009. Total idiots.

http://www.lanacion.com.ar/nota.asp?nota_id=1187055

You can check a site like this to see the correct time:
http://www.timeanddate.com/worldclock/city.html?n=51

The same bug in Fedora and Debian FWIW:
https://bugzilla.redhat.com/show_bug.cgi?id=529691
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551195

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5)
Gecko/20091105 Fedora/3.5.5-1.fc12 Firefox/3.5.5

Comment 1 timeless 2009-12-16 20:50:40 UTC

thanks, 
the "bug" is actually of course in the system time zone data (ours of course
was stale)

this should be fixed in:
glibc 2.5.1-1eglibc22+0m5

I'm not going to do the full marking bits because I don't know how they go, but
I'm sure andre will come along and add them shortly :).

Comment 2 Jeff Moe (reporter) 2010-01-12 20:39:33 UTC

Debian had this fixed in 11 days. Fedora pushed an update *the same day* and
had the update generally available the next day. Two days. Apparently this fix
isn't even in PR1.1. This is a one-liner to fix.

Nokia needs to realize that it can't push enormous drops of code on a single
day every 6 months and keep pace. Incremental daily updates need to be done.
Check how Debian/Fedora and every other major distribution do things. They do
it this way for a reason...Learn it.

Comment 3 Andre Klapper maemo.org

2010-01-12 20:56:50 UTC

Agreeing, but a completely wrong place to post this and nobody will see it
here.

Comment 4 Andre Klapper maemo.org

2010-01-22 13:41:51 UTC

This has been fixed in package
glibc 2.5.1-1eglibc22+0m5
which is part of the internal build version
2009.51-5
(Note: 2009/2010 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.


To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/

Comment 5 Andre Klapper maemo.org

2010-03-15 20:57:04 UTC

Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).