From stephanwehner at gmail.com  Fri Nov 13 14:36:00 2009
From: stephanwehner at gmail.com (Stephan Wehner)
Date: Fri, 13 Nov 2009 11:36:00 -0800
Subject: [TZInfo-users] Resolving local_to_utc ambiguities
Message-ID: <e66d1efb0911131136q2373452bl86aa5228f8ed87be@mail.gmail.com>

Hello there,

At

  http://tzinfo.rubyforge.org/doc/classes/TZInfo/Timezone.html#M000053

it says about the method "Timezone#local_to_utc(local, dst = nil)
{|periods| ...}":

  "If the dst parameter does not resolve the ambiguity, and a block is
specified, it is called."

(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"?

Are there ever more than two elements in the "periods" array that is
passed to the block to pick from?

Thanks,

Stephan

-- 
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

From phil.ross at gmail.com  Sat Nov 14 10:30:55 2009
From: phil.ross at gmail.com (Philip Ross)
Date: Sat, 14 Nov 2009 15:30:55 +0000
Subject: [TZInfo-users] Resolving local_to_utc ambiguities
In-Reply-To: <e66d1efb0911131136q2373452bl86aa5228f8ed87be@mail.gmail.com>
References: <e66d1efb0911131136q2373452bl86aa5228f8ed87be@mail.gmail.com>
Message-ID: <4ac540410911140730y4d4b59cbg34015c06714dcb79@mail.gmail.com>

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:

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: findambigioustz.rb
Type: application/octet-stream
Size: 662 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/tzinfo-users/attachments/20091114/e02c726f/attachment.obj>

From stephanwehner at gmail.com  Mon Nov 16 14:18:04 2009
From: stephanwehner at gmail.com (Stephan Wehner)
Date: Mon, 16 Nov 2009 11:18:04 -0800
Subject: [TZInfo-users] Resolving local_to_utc ambiguities
In-Reply-To: <4ac540410911140730y4d4b59cbg34015c06714dcb79@mail.gmail.com>
References: <e66d1efb0911131136q2373452bl86aa5228f8ed87be@mail.gmail.com>
	<4ac540410911140730y4d4b59cbg34015c06714dcb79@mail.gmail.com>
Message-ID: <e66d1efb0911161118p2c5e82vd214d8da0fe46954@mail.gmail.com>

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