[TZInfo-users] Resolving local_to_utc ambiguities

Stephan Wehner stephanwehner at gmail.com
Mon Nov 16 14:18:04 EST 2009


On Sat, Nov 14, 2009 at 7:30 AM, Philip Ross <phil.ross at gmail.com> wrote:
> Hi Stephan,
>
> 2009/11/13 Stephan Wehner <stephanwehner at gmail.com>:
>> (The ambiguity being that some local times may correspond to several
>> UTC times, for example, when switching to daylight savings time, when
>> there are "two 2 AMs".)
>>
>> In what circumstances would it happen that dst=true or false is not
>> enough to "resolve the ambiguity"?
>
> This will happen when the base UTC offset of a timezone is decreased
> (i.e. the local clocks are put back), but the timezone does not change
> between standard and daylight savings time at the point of change.
>
> There are many instances where this condition happens in the timezone
> data. The attached script will print all of these instances. One of
> the more recent occurrences is the America/Argentina/San_Luis zone,
> where at midnight on 2008-01-21, the clock is put back to 23:00:00 on
> 2008-01-20, but daylight savings time is still observed:

Hi Philip,

thanks for your explanations and the script. To have some examples, I
modified it to look at the instances for the years since 1990. I got
this for my installation (which is good up to 2009):

Africa/Tripoli                 : 1996-09-29T22:00:00+00:00

Africa/Windhoek                : 1994-04-02T22:00:00+00:00

America/Argentina/Catamarca    : 2004-06-01T03:00:00+00:00

America/Argentina/La_Rioja     : 2004-06-01T03:00:00+00:00

America/Argentina/Mendoza      : 2004-05-23T03:00:00+00:00

America/Argentina/Rio_Gallegos : 2004-06-01T03:00:00+00:00

America/Argentina/San_Juan     : 2004-05-31T03:00:00+00:00

America/Argentina/San_Luis     : 2004-05-31T03:00:00+00:00

America/Argentina/San_Luis     : 2009-03-15T03:00:00+00:00

America/Argentina/Tucuman      : 2004-06-01T03:00:00+00:00

America/Argentina/Ushuaia      : 2004-05-30T03:00:00+00:00

America/Cambridge_Bay          : 2000-11-05T05:00:00+00:00

America/Cancun                 : 1998-08-02T06:00:00+00:00

America/Caracas                : 2007-12-09T07:00:00+00:00

America/Guyana                 : 1991-01-01T03:00:00+00:00

America/Managua                : 1992-09-24T05:00:00+00:00

America/Managua                : 1997-01-01T05:00:00+00:00

America/Santo_Domingo          : 2000-10-29T06:00:00+00:00

Asia/Choibalsan                : 2008-03-30T15:00:00+00:00

Asia/Colombo                   : 1996-10-25T18:00:00+00:00

Asia/Colombo                   : 2006-04-14T18:30:00+00:00

Asia/Novosibirsk               : 1993-05-22T16:00:00+00:00

Asia/Tbilisi                   : 2004-06-26T19:00:00+00:00

Europe/Chisinau                : 1990-05-05T21:00:00+00:00

Europe/Kiev                    : 1990-06-30T23:00:00+00:00

Europe/Simferopol              : 1990-06-30T23:00:00+00:00

Europe/Uzhgorod                : 1990-06-30T23:00:00+00:00

Pacific/Kosrae                 : 1998-12-31T12:00:00+00:00


Kind of interesting. Actually, I would think when there are three
options, then the "local people" would get pretty confused and/or
amused.

Thanks again,

Stephan

> America/Argentina/San_Luis  Mon Jan 21 01:59:59 2008 UTC = Sun Jan 20
> 23:59:59 2008 ARST isdst=1
> America/Argentina/San_Luis  Mon Jan 21 02:00:00 2008 UTC = Sun Jan 20
> 23:00:00 2008 WARST isdst=1
>
> If you try to convert 23:30:00 from local time to UTC, then you will
> need to use the block to resolve the ambiguity.
>
>> Are there ever more than two elements in the "periods" array that is
>> passed to the block to pick from?
>
> This could happen if the base UTC offset of a timezone was decreased
> twice in succession. For example, consider a timezone was initially at
> UTC+3, but then put its clocks back to UTC+2 and then an hour later
> put its clocks back to UTC+1:
>
> 03:00 UTC+3 = 00:00 UTC
> 03:59 UTC+3 = 00:59 UTC
> 03:00 UTC+2 = 01:00 UTC
> 03:59 UTC+2 = 01:59 UTC
> 03:00 UTC+1 = 02:00 UTC
>
> In this example, attempting to convert 03:30 from local time to UTC
> would result in three possible periods passed to the block.
>
> I am not however, aware of any such examples in the timezone database,
> so the maxinum number of elements you'll see in the periods array is
> two.
>
> Regards
>
> Phil
>
> --
> Phil Ross
> http://tzinfo.rubyforge.org/ -- DST-aware timezone library for Ruby
>
> _______________________________________________
> TZInfo-users mailing list
> TZInfo-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/tzinfo-users
>



-- 
Stephan Wehner

-> http://stephan.sugarmotor.org (blog and homepage)
-> http://loggingit.com
-> http://www.thrackle.org
-> http://www.buckmaster.ca
-> http://www.trafficlife.com
-> http://stephansmap.org -- http://blog.stephansmap.org


More information about the TZInfo-users mailing list