Problem with Time calculations and daylight saving time

The documentation does reflect this.

Time is an abstraction of dates and times. Time is stored internally as the number of seconds and microseconds since the epoch, January 1, 1970 00:00 UTC. Also see the library modules Date and ParseDate, documented beginning on pages 439 and 453, respectively. The Time class treats GMT (Greenwich Mean Time) and UTC (Coordinated Universal Time)[Yes, UTC really does stand for Coordinated Universal Time. There was a committee involved.] as equivalent. GMT is the older way of referring to these baseline times but persists in the names of calls on Posix systems.

To what documentation do you refer? I was referring to the API documentation of ActiveSupport::CoreExtensions::Time::Calculations on the web.

I probably got something wrong, or maybe I didn't wasn't precise enough.

On my Debian GNU/Linux system when executing

print Time.new

I get the current time according to the time zone I configured (Europe/Berlin which is GMT+1).

The problem occurs when I execute something like this (again with the time zone mentioned above configured on my system):

t = Time.mktime(2005,10,30,0,0,0,0)
print t.tomorrow

This prints "Sun Oct 30 23:00:00 CET 2005" which is not the next day.

I love the idea of the calculation helper module. Being able to use convenience methods like "tommorow" make the code so much more readable.

For rapid prototyping or internal use I like to use the time zone I live in when computing dates and times. According to my understanding libraries and helper modules should hide the complexity of different time zones as much as possible.

So what I hoped to achieve with my bug report was a more robust implementation of "tomorrow" and the other convenience methods that do not require me to convert my Time objects all the .. uhm ... time :-)

If that's not intended, sensible or whatever, I would love to see a small warning in the API documentation of the calculations module. Something like "Might lead to unexpected results in time zones with daylight saving time."

Thanks for your patience.

The Ruby Core Time class can create non-UTC (or with TimeZone) Time objects and in all those methods it specifies, "but interprets the values in the local time zone." Everywhere but in that TimeZone it is the next day, when you use tomorrow. By using the non-UTC creation methods you've already converted your Time objects to nonstandard Time.

Even within UTC the Time values will be incorrect because of Leap seconds, that are voted on by committee. And because of their unpredictability (the approval by majority vote of a leap second) they can't be incorporated. So even time.at_midnight - 1.sec, will occasionally be the same day in UTC, though Ruby Time objects won't show it.

(In [5388]) next_week respects DST changes. Closes #5617, closes #2353, closes #2509, references #4551.