[TZInfo-users] TZInfo::PeriodNotFound exceptions for local_to_utc conversion

Philip Ross philip at ross.org.uk
Fri Feb 16 19:32:37 EST 2007


Mike,

Your message didn't make it to the mailing list because you aren't subscribed.

On 16/02/07, Mike State <mstate at ondogo.com> wrote:
> I was trying to convert a time from local to UTC and I received a
> TZInfo::PeriodNotFound exception.  So I investigated and found that I
> get the same exception for all times within a 1 hour period each
> March and November (dates below).  The code below generates the
> exceptions for the next 3 years.  Am I doing something wrong?  It
> looks like this is when DST kicks in.  Do I need to treat the
> conversions differently for this hour?

This is expected. When switching from standard time to daylight saving
time, the local time skips forward by an hour, for example, going from
01:59:59 to 03:00:00. When switching back to standard time from
daylight saving time an hour of local time will be repeated. For
example, the local time may reach 01:59:59, then go back to 01:00:00
before reaching 01:59:59 again and then 02:00:00.

In the first case (switching to DST), TZInfo will raise a
PeriodNotFound exception if you try to convert a local time that does
not exist. You will need to handle this exception and take appropriate
action. For example, you could inform the user that the time they
specified was not valid, or automatically step forward or back an
hour.

In the second case (switching back from DST), TZInfo will raise an
AmbiguousTime exception indicating that there is more than one
possible UTC time for the specified local time. The local_to_utc
method has two ways of resolving the ambiguity. You can pass a second
Boolean parameter to indicate whether the local time is in daylight
savings, for example:

tz.local_to_utc(Time.utc(2007,11,4,1,3,11), true)
=> Sun Nov 04 05:03:11 UTC 2007
tz.local_to_utc(Time.utc(2007,11,4,1,3,11), false)
=> Sun Nov 04 06:03:11 UTC 2007

Specifying true gives you the first (daylight savings) instance of
01:03:11.  Specifying false gives you the second (standard time)
instance.

local_to_utc can also take a block to resolve the ambiguity. The block
is passed an array of the possible TimezonePeriods and should return
the one to be used for the conversion.

I hope this was of some help. Please let me know if you have any questions.

Phil

-- 
Phil Ross
http://tzinfo.rubyforge.org/ -- DST-aware timezone library for Ruby


More information about the TZInfo-users mailing list