Your close Lionel, actually its due to the switch from Daylight Savings

Time here in the U.S. to Standard Time.

t = Time.parse “Sun October 29 2006”

=> Sun October 29 00:00:00 Pacific Daylight Time 2006

t.since(1.day)

=> Sun October 29 23:00:00 Pacific Standard Time 2006

1.day is really just a shortcut for the number of seconds in a day:

86,400. The same goes for 1.week. It’s really just a shortcut for the

number of seconds in a week: 604,800.

So when you execute the method you did, next_week():

def next_week(day = :monday)

days_into_week = {:monday => 0, :tuesday => 1, :wednesday => 2,

:thursday => 3, :friday => 4, :saturday => 5, :sunday => 6}

since(1.week).beginning_of_week.since(days_into_week[:day].day).change(:hour

=> 0)

end

… with the given date of Monday, October 23rd, it tries to increment

it by adding a weeks worth of seconds to the given date. However, due

to the switch from DST to ST, a weeks worth of seconds only gets you to

11:00PM on Sunday instead of 12:00AM on Monday. Thus the incorrect

date.

I guess technically the bug is with our government ( one of many) in

their continuing this arcane thing called Daylight Savings Time.

However, I believe Ruby provides a method to convert a time to UTC and

then back to your local time. I suppose this might solve the problem by

taking stupid DST out of the equation. I’ll mess around with it and see

if I can create a patch.

Lionel B. wrote:

This is most probably a timezone related bug and not easily solved IMHO.

It seems to me that as in UTC your original date is in fact in the

previous week at some point the next_week method forget to take the TZ

into account. next_week should probably enforce TZ being consistant

across the whole computations (in general this becomes quite tricky when

you mix several Time objects with various TZs in the computation).

This isn’t applicable to your specific problem, but I take the

opportunity to write it there:

The timezone problem being so complex, I only manipulate UTC Time

objects (try t.utc, t.utc.next_week, t.utc.next_week.next_week and

you’ll see the problem doesn’t show up) and convert to localtime only

when needed. Unfortunately, the next_week result is clearly TZ-dependant

so you can’t simply switch to UTC.

Lionel.