Time#since DST issue
Reported by Nauhaie | June 28th, 2008 @ 08:52 AM | in 2.x
Here is some interesting result with Rails 2.1 (without any specific TimeZone configuration).
LONG STORY SHORT:
Loading development environment (Rails 2.1.0)
>> 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
DETAILS:
As you will see, adding 3.hours and then 21.hours doesn't give the same result as adding 24.hours around DST change!
I live in Europe, and DST change just happens at 02:00:00 in my TimeZone (which is most of Europe's). As expected:
>> t = Time.parse("Sun Oct 26 00:30:00 +0200 2008")
=> Sun Oct 26 00:30:00 +0200 2008
>> t2 = t+3.hours
=> Sun Oct 26 02:30:00 +0100 2008
As you can see, the "missing" hour is taken into account, which is what you would expect!
Now, let's add 21 more hours:
>> t2 = t2+21.hours
=> Sun Oct 26 23:30:00 +0100 2008
Which is right, too, since 24.hours have actually passed between the two displayed times!
However, now just try the following:
>> t
=> Sun Oct 26 00:30:00 +0200 2008
>> t3 = t+24.hours
=> Mon Oct 27 00:30:00 +0100 2008
Huho! There is something wrong here!
Is there anything I am missing?
I understand that in some situations, you might want to add "mathematical" hours (which means without taking care of DST or anything specific: 01:00 + 03:00 = 04:00 and that's it). And sometimes, you just want to add "real" hours, which means "what time is it when 3 hours have passed in the real life". Both are equally acceptable approaches. However, some kind of mix between the two is clearly a dangerous solution!
Comments and changes to this ticket
-
Geoff Buesing June 30th, 2008 @ 12:51 AM
- → Tag changed from “2.1 bug timezones” to “bug dst time”
- → State changed from “new” to “open”
- → Title changed from “Rails 2.1 DST Issues” to “Time#since DST issue”
- → Assigned user changed from “” 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 July 10th, 2008 @ 08:32 AM
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 July 11th, 2008 @ 03:36 PM
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
-
Joshua Peek October 28th, 2008 @ 04:25 PM
- → State changed from “open” to “wontfix”
-
Please Login or create a free account to add a new comment.
You can update this ticket by sending an email to from your email client. (help)
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
Source available from github
The Git repository resides at http://github.com/rails
Check out the current development trunk (Edge Rails) with:
git clone git://github.com/rails/rails.git
Creating or reviewing a patch
See the contributor guide.
Creating a feature request
Please don't. If you want a new feature in Rails, you'll have to pull up your sleeves and get busy yourself. Or convince someone else to do it. See the contributor guide on how to get going. But posting them here is just going to lead to ticket root.
Creating a bug report
When creating a bug report, be sure to include as much relevant information as possible. Post the code sample that causes the problem. Preferably, alter the unit tests and show through either changed or added tests how the expected behavior is not occuring.
Security vulnerabilities should be reported via an email to security@rubyonrails.org, do not use trac for reporting security vulnerabilities. All content in trac is publicly available as soon as it is posted.
Then don't get your hopes up. Unless you have a "Code Red, Mission Critical, The World is Coming to an End" kinda bug, you're creating this ticket in the hope that others with the same problem will be able to collaborate with you on solving it. Do not expect that the ticket automatically will see any activity or that others will jump to fix it. Creating a ticket like this is mostly to help yourself start on the path of fixing the problem and for others to sign on to with a "I'm having this problem too".
