' Any help would be greatly appreciated. -- Aaron Patterson http://tenderlovemaking.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From phil.ross at gmail.com Mon Jun 6 17:12:53 2011 From: phil.ross at gmail.com (Philip Ross) Date: Mon, 6 Jun 2011 22:12:53 +0100 Subject: [TZInfo-users] DateTime.new! removal from ruby-core In-Reply-To: <20110606172857.GA41473@higgins.local> References: <20110606172857.GA41473@higgins.local> Message-ID: Hi Aaron, On 6 June 2011 18:28, Aaron Patterson wrote: > I filed a ticket a while back about DateTime.new! being removed from > ruby-core. ?It looks like that was fixed, and replaced with using > DateTime.jd (thanks!) Yes, I changed the code to fall-back to using DateTime.jd if DateTime.new! is not available. > When I run with 1.9.3dev, I get this: > > ? ?/Users/aaron/svn/tzinfo/tzinfo/lib/tzinfo/ruby_core_support.rb:63:in `jd': invalid fraction (ArgumentError) > ? ? ? ? ? ?from /Users/aaron/svn/tzinfo/tzinfo/lib/tzinfo/ruby_core_support.rb:63:in `datetime_new!' > ? ? ? ? ? ?from test.rb:5:in `

' I think this is being caused by a bug in Ruby's date library, introduced in revision 31862, that prevents more than one argument from being passed to DateTime.jd. I've raised this issue in RedMine as bug #4848. http://redmine.ruby-lang.org/issues/4848 Kind regards, Phil From phil.ross at gmail.com Sat Jun 11 21:22:34 2011 From: phil.ross at gmail.com (Philip Ross) Date: Sun, 12 Jun 2011 02:22:34 +0100 Subject: [TZInfo-users] DateTime.new! removal from ruby-core In-Reply-To: References: <20110606172857.GA41473@higgins.local> Message-ID: On 6 June 2011 22:12, Philip Ross wrote: >> When I run with 1.9.3dev, I get this: >> >> ? ?/Users/aaron/svn/tzinfo/tzinfo/lib/tzinfo/ruby_core_support.rb:63:in `jd': invalid fraction (ArgumentError) >> ? ? ? ? ? ?from /Users/aaron/svn/tzinfo/tzinfo/lib/tzinfo/ruby_core_support.rb:63:in `datetime_new!' >> ? ? ? ? ? ?from test.rb:5:in `

' > > I think this is being caused by a bug in Ruby's date library, > introduced in revision 31862, that prevents more than one argument > from being passed to DateTime.jd. This is apparently not a bug in Ruby, but a change in the behaviour of the DateTime.jd method. DateTime.jd will no longer accept a fractional Julian Day number if any of the subsequent parameters are specified. I've made a change in svn (revisions 314 and 316 in the 0.3 branch) to support the new behaviour of the DateTime.jd method. This will be included in the next TZInfo release. Kind regards, Phil From kurt at circlew.org Mon Jun 20 13:22:35 2011 From: kurt at circlew.org (Kurt Werle) Date: Mon, 20 Jun 2011 10:22:35 -0700 Subject: [TZInfo-users] I'd rather not be AmbiguousTime Message-ID: I use several 3rd party gems (ri_cal and others) that can generate times for me. These libraries sometimes wander into AmbiguousTimes - when they are generating repeat events, for example. I would rather not have to worry about AmbiguousTimes, ever. It seems like a simple solution is to provide a default for the dst value that is passed in when generating local times. To this end, I have attached the included patch file, complete with tests. Timezone.default_dst= true/false[/nil] I hope it can be integrated into tzinfo in the near future. Thanks! Kurt -- kurt at CircleW.org http://www.CircleW.org/kurt/ -------------- next part -------------- A non-text attachment was scrubbed... Name: tzinfo.patch Type: application/octet-stream Size: 3169 bytes Desc: not available URL: From phil.ross at gmail.com Tue Jun 21 18:16:03 2011 From: phil.ross at gmail.com (Philip Ross) Date: Tue, 21 Jun 2011 23:16:03 +0100 Subject: [TZInfo-users] I'd rather not be AmbiguousTime In-Reply-To: References: Message-ID: Hi Kurt, On 20 June 2011 18:22, Kurt Werle wrote: > I use several 3rd party gems (ri_cal and others) that can generate > times for me. ?These libraries sometimes wander into AmbiguousTimes - > when they are generating repeat events, for example. > > I would rather not have to worry about AmbiguousTimes, ever. ?It seems > like a simple solution is to provide a default for the dst value that > is passed in when generating local times. ?To this end, I have > attached the included patch file, complete with tests. Thanks for the suggestion and your patch. > I hope it can be integrated into tzinfo in the near future. I have committed your patch to svn. The change will be included in the next release. In the commit, I also set the default value of the dst parameter of the local_to_utc method to default_dst. Without this, local_to_utc would still raise an AmbiguousTime exception in transitions from daylight savings time. I also made a change to the test cases to make sure default_dst was reset back to nil after being changed to avoid having an impact on any of the other test cases. Kind regards, Phil From kurt at circlew.org Tue Jun 21 19:46:28 2011 From: kurt at circlew.org (Kurt Werle) Date: Tue, 21 Jun 2011 16:46:28 -0700 Subject: [TZInfo-users] I'd rather not be AmbiguousTime In-Reply-To: References:

Message-ID: > I have committed your patch to svn. The change will be included in the > next release. Not to be pushy, but do you have any notion of when that might be? > In the commit, I also set the default value of the dst parameter of > the local_to_utc method to default_dst. Without this, local_to_utc > would still raise an AmbiguousTime exception in transitions from > daylight savings time. I should have caught that! > I also made a change to the test cases to make sure default_dst was > reset back to nil after being changed to avoid having an impact on any > of the other test cases. And that. Thanks for all your work, Kurt -- kurt at CircleW.org http://www.CircleW.org/kurt/ From phil.ross at gmail.com Mon Jun 27 17:10:08 2011 From: phil.ross at gmail.com (Philip Ross) Date: Mon, 27 Jun 2011 22:10:08 +0100 Subject: [TZInfo-users] I'd rather not be AmbiguousTime In-Reply-To: References:

Message-ID: Hi Kurt, Sorry for the delay in getting back to you. On 22 June 2011 00:46, Kurt Werle wrote: >> I have committed your patch to svn. The change will be included in the >> next release. > > Not to be pushy, but do you have any notion of when that might be? I'm aiming to release a new version later today. This will also contain the recent changes to the Russian timezones. Kind regards, Phil