This project is archived and is in readonly mode.
Time#since DST issue
-
Geoff Buesing
- Title changed from Rails 2.1 DST Issues to Time#since DST issue
- State changed from new to open
- Tag changed from 2.1, bug, timezones to bug, dst, time
- Assigned user set to Geoff Buesing
I think this is because Time#since does a DST adjustment if the passed-in value is >= 86400 seconds -- hence, the difference between adding 24.hours and adding 3.hours + 21.hours.
I think this behavior is a vestige from before Rails had the Duration class, so that you could do time.since(1.day) and have it adjust for DST changes. W should probably revisit this.
If someone could write up a failing test case for this, that would be helpful.
-
Nauhaie
Hi Geoff,
Thank's for your commit! But I still have the same problem :-(
Loading development environment (Rails 2.0.991)
>> t = Time.parse("Sun Oct 26 00:30:00 +0200 2008")
=> Sun Oct 26 00:30:00 +0200 2008
>> (t+24.hours)==((t+3.hours)+21.hours)
=> false
I think 24.hours, 21.hours and 3.hours are fixed-length time intervals, right?
Here is how I got it:
rails test_edge && cd test_edge
rake rails:freeze:edge
Then, I replaced the time_with_zone.rb in my vendor dir with your modified version
./script/console
I did not set up anything else, and the problem is still the same...
How is it possible?
Thank you,
Nauhaie
-
Geoff Buesing
Hi Nahuaie,
I committed a similar fix to the TimeWithZone class, but the issue with the plain old Ruby Time class identified in this ticket is still outstanding.
If you want to use the TimeWithZone class, you'll need to turn on config.time_zone for your app. See this tutorial for more.
Geoff
-
josh
- State changed from open to wontfix
-
Nauhaie
I am sorry, but why "wontfix"?