From siva at yewoh.com  Wed Jan 23 12:28:30 2008
From: siva at yewoh.com (Siva Jagadeesan)
Date: Wed, 23 Jan 2008 11:28:30 -0600
Subject: [TZInfo-users] "can't modify frozen object"
Message-ID: <160B8340-B8C4-4FD2-9622-2ECEA9C7C09F@yewoh.com>

Hi all

At yewoh.com , we keep randomly getting "can't modify frozen object"  
error.

Any idea?

Rgds,

--Siva Jagadeesan

www.yewoh.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/tzinfo-users/attachments/20080123/845c3553/attachment.html 

From phil.ross at gmail.com  Wed Jan 23 15:21:17 2008
From: phil.ross at gmail.com (Philip Ross)
Date: Wed, 23 Jan 2008 20:21:17 +0000
Subject: [TZInfo-users] "can't modify frozen object"
In-Reply-To: <160B8340-B8C4-4FD2-9622-2ECEA9C7C09F@yewoh.com>
References: <160B8340-B8C4-4FD2-9622-2ECEA9C7C09F@yewoh.com>
Message-ID: <4ac540410801231221k3ac23395s610ba2028cb8fae9@mail.gmail.com>

On 23/01/2008, Siva Jagadeesan <siva at yewoh.com> wrote:
> Hi all
>
> At yewoh.com , we keep randomly getting "can't modify frozen object" error.
>
> Any idea?

Hi Siva,

It's a bit difficult to work out what is going on from just that error
message alone. It may not be anything to do with TZInfo. If you've got
a stack trace for the error in your logs, it should tell you what is
causing the problems.

TZInfo does use the freeze method to protect some of the arrays that
are returned. If you are accessing these methods and then attempting
to modify the results, then this may be the cause of the problem.

Regards,

Phil

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

From siva at yewoh.com  Wed Jan 23 15:43:53 2008
From: siva at yewoh.com (Siva Jagadeesan)
Date: Wed, 23 Jan 2008 14:43:53 -0600
Subject: [TZInfo-users] "can't modify frozen object"
In-Reply-To: <4ac540410801231221k3ac23395s610ba2028cb8fae9@mail.gmail.com>
References: <160B8340-B8C4-4FD2-9622-2ECEA9C7C09F@yewoh.com>
	<4ac540410801231221k3ac23395s610ba2028cb8fae9@mail.gmail.com>
Message-ID: <C0AD9663-D211-4FDE-A3B0-1460358F1DBA@yewoh.com>

Thanks Phil for replying.

We are using  tzinfo_timezone plugin for changing dates before  
displaying or storing it the database.


This is the exception stack trace

A ActionView::TemplateError occurred in groups#load_app:

can't modify frozen object
On line #7 of app/views/groups/_groups_smslist.haml

   4:       - c = 0
   5:       - for post in recent_posts
   6:         %div{:class=>'smslist_' + (c % 2).to_s}
   7:           = post.text +  ' by ' + b(post.author.login) + ' on '  
+ b(post.channel.name) + i(' (' + post.created_at.to_human_label + ')')
   8:         - c = c+1
   9:   - else
   10:     %i There are no posts yet!
   #{RAILS_ROOT}/app/views/groups/_groups_smslist.haml:7
   #{RAILS_ROOT}/vendor/plugins/tzinfo_timezone/lib/tzinfo_timezone.rb: 
215:in `tzinfo'
   #{RAILS_ROOT}/vendor/plugins/tzinfo_timezone/lib/tzinfo_timezone.rb: 
189:in `utc_to_local'
   #{RAILS_ROOT}/vendor/plugins/tztime/lib/tz_time_helpers/ 
active_record_methods.rb:16:in `created_at'
   (eval):22:in `_render_haml_11'
   (eval):18:in `each'
   (eval):18:in `_render_haml_11'
   #{RAILS_ROOT}/vendor/plugins/haml/lib/haml/engine.rb:431:in `send'
   #{RAILS_ROOT}/vendor/plugins/haml/lib/haml/engine.rb:431:in `compile'
   #{RAILS_ROOT}/vendor/plugins/haml/lib/haml/engine.rb:183:in `to_html'
   #{RAILS_ROOT}/vendor/plugins/haml/lib/haml/template.rb:69:in `render'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb: 
416:in `delegate_render'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb: 
299:in `render_template_old'
   #{RAILS_ROOT}/vendor/plugins/haml/lib/haml/template.rb:96:in  
`render_template'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb: 
260:in `render_file'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb: 
275:in `render_without_haml'
   #{RAILS_ROOT}/vendor/plugins/haml/lib/haml/helpers/ 
action_view_mods.rb:17:in `render'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/partials.rb: 
59:in `render_partial'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
benchmarking.rb:30:in `benchmark'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/partials.rb: 
58:in `render_partial'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb: 
287:in `render_without_haml'
   #{RAILS_ROOT}/vendor/plugins/haml/lib/haml/helpers/ 
action_view_mods.rb:17:in `render'
   (eval):11:in `_render_haml_35'
   #{RAILS_ROOT}/vendor/plugins/haml/lib/haml/engine.rb:431:in `send'
   #{RAILS_ROOT}/vendor/plugins/haml/lib/haml/engine.rb:431:in `compile'
   #{RAILS_ROOT}/vendor/plugins/haml/lib/haml/engine.rb:183:in `to_html'
   #{RAILS_ROOT}/vendor/plugins/haml/lib/haml/template.rb:69:in `render'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb: 
416:in `delegate_render'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb: 
299:in `render_template_old'
   #{RAILS_ROOT}/vendor/plugins/haml/lib/haml/template.rb:96:in  
`render_template'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb: 
260:in `render_file'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb: 
275:in `render_without_haml'
   #{RAILS_ROOT}/vendor/plugins/haml/lib/haml/helpers/ 
action_view_mods.rb:17:in `render'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/partials.rb: 
59:in `render_partial'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
benchmarking.rb:30:in `benchmark'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/partials.rb: 
58:in `render_partial'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb: 
287:in `render_without_haml'
   #{RAILS_ROOT}/vendor/plugins/haml/lib/haml/helpers/ 
action_view_mods.rb:17:in `render'
   (eval):24:in `_render_haml_32'
   #{RAILS_ROOT}/vendor/plugins/haml/lib/haml/engine.rb:431:in `send'
   #{RAILS_ROOT}/vendor/plugins/haml/lib/haml/engine.rb:431:in `compile'
   #{RAILS_ROOT}/vendor/plugins/haml/lib/haml/engine.rb:183:in `to_html'
   #{RAILS_ROOT}/vendor/plugins/haml/lib/haml/template.rb:69:in `render'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb: 
416:in `delegate_render'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb: 
299:in `render_template_old'
   #{RAILS_ROOT}/vendor/plugins/haml/lib/haml/template.rb:96:in  
`render_template'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb: 
260:in `render_file'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb: 
275:in `render_without_haml'
   #{RAILS_ROOT}/vendor/plugins/haml/lib/haml/helpers/ 
action_view_mods.rb:17:in `render'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/partials.rb: 
59:in `render_partial'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
benchmarking.rb:30:in `benchmark'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/partials.rb: 
58:in `render_partial'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb: 
287:in `render_without_haml'
   #{RAILS_ROOT}/vendor/plugins/haml/lib/haml/helpers/ 
action_view_mods.rb:17:in `render'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/helpers/ 
prototype_helper.rb:597:in `render'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/helpers/ 
prototype_helper.rb:459:in `replace_html'
   #{RAILS_ROOT}/app/controllers/application.rb:90:in  
`render_application'
   #{RAILS_ROOT}/app/controllers/application.rb:17:in  
`__bind_1201115799_598358'
   #{RAILS_ROOT}/vendor/rails/activesupport/lib/active_support/ 
core_ext/object/extending.rb:44:in `[]'
   #{RAILS_ROOT}/vendor/rails/activesupport/lib/active_support/ 
core_ext/object/extending.rb:44:in `instance_exec'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/helpers/ 
prototype_helper.rb:313:in `initialize'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/base.rb: 
769:in `new'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/base.rb: 
769:in `render_with_no_layout'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
layout.rb:256:in `render_without_benchmark'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
benchmarking.rb:50:in `render'
   /usr/lib/ruby/1.8/benchmark.rb:293:in `measure'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
benchmarking.rb:50:in `render'
   #{RAILS_ROOT}/app/controllers/application.rb:16:in `load_app'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/base.rb: 
1095:in `send'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/base.rb: 
1095:in `perform_action_without_filters'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
filters.rb:632:in `call_filter'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
filters.rb:638:in `call_filter'
   #{RAILS_ROOT}/app/controllers/application.rb:111:in `set_timezone'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
filters.rb:456:in `send'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
filters.rb:456:in `call'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
filters.rb:637:in `call_filter'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
filters.rb:638:in `call_filter'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
filters.rb:438:in `call'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
filters.rb:637:in `call_filter'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
filters.rb:638:in `call_filter'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
filters.rb:438:in `call'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
filters.rb:637:in `call_filter'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
filters.rb:638:in `call_filter'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
filters.rb:449:in `call'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
filters.rb:637:in `call_filter'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
filters.rb:619:in `perform_action_without_benchmark'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
benchmarking.rb:66:in `perform_action_without_rescue'
   /usr/lib/ruby/1.8/benchmark.rb:293:in `measure'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
benchmarking.rb:66:in `perform_action_without_rescue'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
rescue.rb:83:in `perform_action'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/base.rb: 
430:in `send'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/base.rb: 
430:in `process_without_filters'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
filters.rb:624:in `process_without_session_management_support'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/ 
session_management.rb:114:in `sass_old_process'
   #{RAILS_ROOT}/vendor/plugins/haml/lib/sass/plugin.rb:124:in `process'
   #{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/base.rb: 
330:in `process'
   #{RAILS_ROOT}/vendor/rails/railties/lib/dispatcher.rb:41:in  
`dispatch'
   /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.3/lib/mongrel/rails.rb: 
76:in `process'
   /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.3/lib/mongrel/rails.rb: 
74:in `synchronize'
   /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.3/lib/mongrel/rails.rb: 
74:in `process'
   /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.3/lib/mongrel.rb:159:in  
`process_client'
   /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.3/lib/mongrel.rb:158:in  
`each'
   /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.3/lib/mongrel.rb:158:in  
`process_client'
   /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.3/lib/mongrel.rb:285:in `run'
   /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.3/lib/mongrel.rb:285:in  
`initialize'
   /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.3/lib/mongrel.rb:285:in `new'
   /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.3/lib/mongrel.rb:285:in `run'
   /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.3/lib/mongrel.rb:268:in  
`initialize'
   /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.3/lib/mongrel.rb:268:in `new'
   /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.3/lib/mongrel.rb:268:in `run'
   /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.3/lib/mongrel/ 
configurator.rb:282:in `run'
   /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.3/lib/mongrel/ 
configurator.rb:281:in `each'
   /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.3/lib/mongrel/ 
configurator.rb:281:in `run'
   /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.3/bin/mongrel_rails:128:in  
`run'
   /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.3/lib/mongrel/command.rb: 
212:in `run'
   /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.3/bin/mongrel_rails:281
   /usr/bin/mongrel_rails:16:in `load'
   /usr/bin/mongrel_rails:16

The exception is happening in that plugin. I am not sure what is  
happening. Has anybody else have come across this problem?

Rgds,

--Siva Jagadeesan

On Jan 23, 2008, at 2:21 PM, Philip Ross wrote:

> On 23/01/2008, Siva Jagadeesan <siva at yewoh.com> wrote:
>> Hi all
>>
>> At yewoh.com , we keep randomly getting "can't modify frozen  
>> object" error.
>>
>> Any idea?
>
> Hi Siva,
>
> It's a bit difficult to work out what is going on from just that error
> message alone. It may not be anything to do with TZInfo. If you've got
> a stack trace for the error in your logs, it should tell you what is
> causing the problems.
>
> TZInfo does use the freeze method to protect some of the arrays that
> are returned. If you are accessing these methods and then attempting
> to modify the results, then this may be the cause of the problem.
>
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/tzinfo-users/attachments/20080123/359c80ba/attachment-0001.html 

From phil.ross at gmail.com  Wed Jan 23 17:44:57 2008
From: phil.ross at gmail.com (Philip Ross)
Date: Wed, 23 Jan 2008 22:44:57 +0000
Subject: [TZInfo-users] "can't modify frozen object"
In-Reply-To: <C0AD9663-D211-4FDE-A3B0-1460358F1DBA@yewoh.com>
References: <160B8340-B8C4-4FD2-9622-2ECEA9C7C09F@yewoh.com>
	<4ac540410801231221k3ac23395s610ba2028cb8fae9@mail.gmail.com>
	<C0AD9663-D211-4FDE-A3B0-1460358F1DBA@yewoh.com>
Message-ID: <4ac540410801231444x6f812794r1509890970c4fef@mail.gmail.com>

On 23/01/2008, Siva Jagadeesan <siva at yewoh.com> wrote:
> Thanks Phil for replying.
>
> We are using  tzinfo_timezone plugin for changing dates before displaying or
> storing it the database.
>
> The exception is happening in that plugin. I am not sure what is happening.
> Has anybody else have come across this problem?

Hi Siva,

Yes, I agree - it looks like the exception is being raised in the
tzinfo_timezone plugin. It also looks like you are not alone in
experiencing the problem
(http://google.com/search?q=tzinfo_timezone+%22can%27t+modify+frozen+object%22),
but no one seems to have posted a solution yet.

Your call to post.created_at is returning you a TzTime object which
contains a TzinfoTimezone instance. It looks like this instance has
become frozen, causing the TzinfoTimezone#tzinfo method to raise an
exception on line 215 running the following:

  @tzinfo = MAPPING[name])

I'm not sure what would have caused the TzinfoTimezone instance to
become frozen though. Perhaps you could modify tzinfo_timezone.rb,
overriding the freeze method to try and determine what is calling
freeze in the first place?

Regards,

Phil

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

From siva at yewoh.com  Wed Jan 23 18:16:49 2008
From: siva at yewoh.com (Siva Jagadeesan)
Date: Wed, 23 Jan 2008 17:16:49 -0600
Subject: [TZInfo-users] "can't modify frozen object"
In-Reply-To: <4ac540410801231444x6f812794r1509890970c4fef@mail.gmail.com>
References: <160B8340-B8C4-4FD2-9622-2ECEA9C7C09F@yewoh.com>
	<4ac540410801231221k3ac23395s610ba2028cb8fae9@mail.gmail.com>
	<C0AD9663-D211-4FDE-A3B0-1460358F1DBA@yewoh.com>
	<4ac540410801231444x6f812794r1509890970c4fef@mail.gmail.com>
Message-ID: <C95BF8BD-5C33-436B-86EA-8267010C41FD@yewoh.com>

Thanks Phil.

Let me try your suggestion. I will let you know if I find something.


On Jan 23, 2008, at 4:44 PM, Philip Ross wrote:

> On 23/01/2008, Siva Jagadeesan <siva at yewoh.com> wrote:
>> Thanks Phil for replying.
>>
>> We are using  tzinfo_timezone plugin for changing dates before  
>> displaying or
>> storing it the database.
>>
>> The exception is happening in that plugin. I am not sure what is  
>> happening.
>> Has anybody else have come across this problem?
>
> Hi Siva,
>
> Yes, I agree - it looks like the exception is being raised in the
> tzinfo_timezone plugin. It also looks like you are not alone in
> experiencing the problem
> (http://google.com/search?q=tzinfo_timezone+%22can%27t+modify+frozen+object%22 
> ),
> but no one seems to have posted a solution yet.
>
> Your call to post.created_at is returning you a TzTime object which
> contains a TzinfoTimezone instance. It looks like this instance has
> become frozen, causing the TzinfoTimezone#tzinfo method to raise an
> exception on line 215 running the following:
>
>  @tzinfo = MAPPING[name])
>
> I'm not sure what would have caused the TzinfoTimezone instance to
> become frozen though. Perhaps you could modify tzinfo_timezone.rb,
> overriding the freeze method to try and determine what is calling
> freeze in the first place?
>
> 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


From dburkes at infoteria.com  Mon Jan 28 17:13:01 2008
From: dburkes at infoteria.com (Danny Burkes)
Date: Mon, 28 Jan 2008 14:13:01 -0800
Subject: [TZInfo-users] local_to_utc failure
Message-ID: <96F3C1D7-06FC-43B9-A1EC-61A46F331EA4@infoteria.com>

Perhaps this is just my misunderstanding, but it appears as a bug to  
me, using tzinfo 0.3.6.  Using the 'Buenos Aires' timezone,  
local_to_utc conversions for local times during the DST transition in  
December 2007, always throw TzInfo::PeriodNotFound.

	tz = TimeZone['Buenos Aires']
	tz.local_to_utc(DateTime.new(2007,12,30,0,30,0), true)  -> throws  
TzInfo::PeriodNotFound
	tz.local_to_utc(DateTime.new(2007,12,30,0,30,0), false)  -> throws  
TzInfo::PeriodNotFound

Shouldn't these local_to_utc calls succeed?

Thank you,

Danny Burkes

From dburkes at infoteria.com  Mon Jan 28 19:24:23 2008
From: dburkes at infoteria.com (Danny Burkes)
Date: Mon, 28 Jan 2008 16:24:23 -0800
Subject: [TZInfo-users] local_to_utc failure
In-Reply-To: <96F3C1D7-06FC-43B9-A1EC-61A46F331EA4@infoteria.com>
References: <96F3C1D7-06FC-43B9-A1EC-61A46F331EA4@infoteria.com>
Message-ID: <1A46064C-A4D9-4AD7-AFD2-3C6FC04F8D10@infoteria.com>

Sorry- I put the previous code sample in terms of Rails'  
tzinfo_timezone plugin.  Here is some "raw" tzinfo code that  
illustrates the bug:

irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> gem 'tzinfo', "0.3.6"
=> true
irb(main):003:0> require 'tzinfo'
=> true
irb(main):004:0>  tz = TZInfo::Timezone.get('America/Argentina/ 
Buenos_Aires')
=> #<TZInfo::DataTimezone: America/Argentina/Buenos_Aires>
irb(main):005:0> tz.local_to_utc(DateTime.new(2007,12,30,0,30,0))
TZInfo::PeriodNotFound: TZInfo::PeriodNotFound

If I use tzinfo 0.3.5, all is well-

irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> gem 'tzinfo', "0.3.5"
=> true
irb(main):003:0> require 'tzinfo'
=> true
irb(main):004:0> tz = TZInfo::Timezone.get('America/Argentina/ 
Buenos_Aires')
=> #<TZInfo::DataTimezone: America/Argentina/Buenos_Aires>
irb(main):005:0> tz.local_to_utc(DateTime.new(2007,12,30,0,30,0))
=> #<DateTime: 117814303/48,0,2299161>
irb(main):006:0>

- Danny

From phil.ross at gmail.com  Tue Jan 29 05:22:21 2008
From: phil.ross at gmail.com (Philip Ross)
Date: Tue, 29 Jan 2008 10:22:21 +0000
Subject: [TZInfo-users] local_to_utc failure
In-Reply-To: <1A46064C-A4D9-4AD7-AFD2-3C6FC04F8D10@infoteria.com>
References: <96F3C1D7-06FC-43B9-A1EC-61A46F331EA4@infoteria.com>
	<1A46064C-A4D9-4AD7-AFD2-3C6FC04F8D10@infoteria.com>
Message-ID: <4ac540410801290222u1a8f6467g7d6ff8b539fe84d4@mail.gmail.com>

On 29/01/2008, Danny Burkes <dburkes at infoteria.com> wrote:
> Sorry- I put the previous code sample in terms of Rails'
> tzinfo_timezone plugin.  Here is some "raw" tzinfo code that
> illustrates the bug:
>
> irb(main):004:0>  tz = TZInfo::Timezone.get('America/Argentina/
> Buenos_Aires')
> => #<TZInfo::DataTimezone: America/Argentina/Buenos_Aires>
> irb(main):005:0> tz.local_to_utc(DateTime.new(2007,12,30,0,30,0))
> TZInfo::PeriodNotFound: TZInfo::PeriodNotFound
>
> If I use tzinfo 0.3.5, all is well-
>
> irb(main):004:0> tz = TZInfo::Timezone.get('America/Argentina/
> Buenos_Aires')
> => #<TZInfo::DataTimezone: America/Argentina/Buenos_Aires>
> irb(main):005:0> tz.local_to_utc(DateTime.new(2007,12,30,0,30,0))
> => #<DateTime: 117814303/48,0,2299161>
> irb(main):006:0>

Hi Danny,

This is a valid change between 0.3.5 and 0.3.6. Version 0.3.6 upgraded
the version of the tz data to 2007k which included a change to the
Argentina daylight savings rules (see
http://article.gmane.org/gmane.comp.time.tz/2013).

Argentina adopted daylight savings again at midnight local time on 30
December 2007. At midnight, the time moved forward an hour. Therefore,
the local times between midnight and 1am did not actually exist.
TZInfo raises the PeriodNotFound exception to indicate this condition.

Regards,

Phil

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

From dburkes at infoteria.com  Tue Jan 29 11:43:26 2008
From: dburkes at infoteria.com (Danny Burkes)
Date: Tue, 29 Jan 2008 08:43:26 -0800
Subject: [TZInfo-users] local_to_utc failure
In-Reply-To: <4ac540410801290222u1a8f6467g7d6ff8b539fe84d4@mail.gmail.com>
References: <96F3C1D7-06FC-43B9-A1EC-61A46F331EA4@infoteria.com>
	<1A46064C-A4D9-4AD7-AFD2-3C6FC04F8D10@infoteria.com>
	<4ac540410801290222u1a8f6467g7d6ff8b539fe84d4@mail.gmail.com>
Message-ID: <F5A45983-149F-4AC1-834A-26E60FDCBE64@infoteria.com>

Sorry, I left out a crucial piece of code :-)

It throws PeriodNotFound, even if I pass the dst flag to  
local_to_utc.  Viz-

irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> gem 'tzinfo', "0.3.6"
=> true
irb(main):003:0> require 'tzinfo'
=> true
irb(main):004:0> tz = TZInfo::Timezone.get('America/Argentina/ 
Buenos_Aires')
=> #<TZInfo::DataTimezone: America/Argentina/Buenos_Aires>
irb(main):005:0> tz.local_to_utc(DateTime.new(2007,12,30,0,30,0), true)
TZInfo::PeriodNotFound: TZInfo::PeriodNotFound
        from /opt/local/lib/ruby/gems/1.8/gems/tzinfo-0.3.6/lib/tzinfo/ 
timezone.rb:338:in `period_for_local'
        from /opt/local/lib/ruby/gems/1.8/gems/tzinfo-0.3.6/lib/tzinfo/ 
timezone.rb:417:in `local_to_utc'
        from /opt/local/lib/ruby/gems/1.8/gems/tzinfo-0.3.6/lib/tzinfo/ 
time_or_datetime.rb:276:in `wrap'
        from /opt/local/lib/ruby/gems/1.8/gems/tzinfo-0.3.6/lib/tzinfo/ 
timezone.rb:413:in `local_to_utc'
        from (irb):5
irb(main):006:0> tz.local_to_utc(DateTime.new(2007,12,30,0,30,0), false)
TZInfo::PeriodNotFound: TZInfo::PeriodNotFound
        from /opt/local/lib/ruby/gems/1.8/gems/tzinfo-0.3.6/lib/tzinfo/ 
timezone.rb:338:in `period_for_local'
        from /opt/local/lib/ruby/gems/1.8/gems/tzinfo-0.3.6/lib/tzinfo/ 
timezone.rb:417:in `local_to_utc'
        from /opt/local/lib/ruby/gems/1.8/gems/tzinfo-0.3.6/lib/tzinfo/ 
time_or_datetime.rb:276:in `wrap'
        from /opt/local/lib/ruby/gems/1.8/gems/tzinfo-0.3.6/lib/tzinfo/ 
timezone.rb:413:in `local_to_utc'
        from (irb):6
irb(main):007:0>

My understanding from the docs is that, if I pass the dst flag to  
local_to_utc, it should never throw the exception.  Am I  
misunderstanding?

Best Regards,

Danny

From phil.ross at gmail.com  Tue Jan 29 11:57:17 2008
From: phil.ross at gmail.com (Philip Ross)
Date: Tue, 29 Jan 2008 16:57:17 +0000
Subject: [TZInfo-users] local_to_utc failure
In-Reply-To: <F5A45983-149F-4AC1-834A-26E60FDCBE64@infoteria.com>
References: <96F3C1D7-06FC-43B9-A1EC-61A46F331EA4@infoteria.com>
	<1A46064C-A4D9-4AD7-AFD2-3C6FC04F8D10@infoteria.com>
	<4ac540410801290222u1a8f6467g7d6ff8b539fe84d4@mail.gmail.com>
	<F5A45983-149F-4AC1-834A-26E60FDCBE64@infoteria.com>
Message-ID: <4ac540410801290857w75e6d49bl7c81dc3c540e7f61@mail.gmail.com>

On 29/01/2008, Danny Burkes <dburkes at infoteria.com> wrote:
> Sorry, I left out a crucial piece of code :-)
>
> It throws PeriodNotFound, even if I pass the dst flag to
> local_to_utc.  Viz-
>
> My understanding from the docs is that, if I pass the dst flag to
> local_to_utc, it should never throw the exception.  Am I
> misunderstanding?

Hi Danny,

The dst flag is only used to resolve the ambiguity when an
AmbiguousTime exception is raised. When transitioning from daylight
savings time to standard time, there will be an hour in local time for
which there are two equivalent UTC times. For example, suppose the
transition from dst to standard time occurred at 2am local time. Local
time would reach 01:59:59 and then go back to 01:00:00 again, causing
the hour from 1am to 2pm would be repeated. The dst parameter allows
you to select whether you want the UTC time corresponding with the dst
local time (the first occurrence) or the standard local time (the
second occurrence).

A PeriodNotFound exception is raised in the opposite case, when
transitioning from standard time to daylight savings time. In the case
you are looking at, local time went from 23:59:59 to 01:00:00. The
hour between midnight and 1am does not exist in local time.

The dst flag has no affect on PeriodNotFound exceptions. To resolve
this, you'll have to handle the error and then decide what is sensible
for your application - e.g. manually adding an hour to the local time
and then converting again.

Regards,

Phil

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

From dburkes at infoteria.com  Tue Jan 29 12:49:57 2008
From: dburkes at infoteria.com (Danny Burkes)
Date: Tue, 29 Jan 2008 09:49:57 -0800
Subject: [TZInfo-users] local_to_utc failure
In-Reply-To: <4ac540410801290857w75e6d49bl7c81dc3c540e7f61@mail.gmail.com>
References: <96F3C1D7-06FC-43B9-A1EC-61A46F331EA4@infoteria.com>
	<1A46064C-A4D9-4AD7-AFD2-3C6FC04F8D10@infoteria.com>
	<4ac540410801290222u1a8f6467g7d6ff8b539fe84d4@mail.gmail.com>
	<F5A45983-149F-4AC1-834A-26E60FDCBE64@infoteria.com>
	<4ac540410801290857w75e6d49bl7c81dc3c540e7f61@mail.gmail.com>
Message-ID: <8A81B0DA-2D17-4ADA-B643-A357A5DF1077@infoteria.com>

> The dst flag has no affect on PeriodNotFound exceptions. To resolve
> this, you'll have to handle the error and then decide what is sensible
> for your application - e.g. manually adding an hour to the local time
> and then converting again.
>

Ah- a closer reading of the docs indicates that I am a dork.

Thanks for the clarification!

Best Regards,

Danny