Advancing out of Daylight Savings Time

[james2m]

On Sunday, November 1, 2015 at 2:00 a.m (Eastern Time) the US clocks jump out of Daylight Savings time.

Given this config

      WorkingHours::Config.time_zone = 'America/New_York'
      WorkingHours::Config.working_hours = {
        sat: {'02:00' => '17:00'},
        sun: {'02:00' => '17:00'},
        tue: {'02:00' => '17:00'}
      }

How would you expect

advance_to_working_time(Time.new(2015, 11, 1, 1, 59, 30, '-04:00'))

To behave? I would think that it should return;

Time.new(2015, 11, 1, 2, 0, 0, '-05:00')

As that is the new 02:00, 5 hours behind UTC. Currently we are getting;

Time.new(2015, 11, 1, 1, 0, 0, '-05:00')

Before doing anything about this I wanted to check if this is how you'd expect to handle 'Jump back' events?

I'd also make the same assumption about 'Spring forward'.

[jarthod]

Haha, yeah that's the tricky case everyone loves. You're right, 2:00 -05:00 seems like the most logical output. If you have a good fix please go ahead, this is usually hard to tackle without introducing other weird behaviors.

[james2m]

Yup, hard to tackle. Or at least hard to tackle consistently advancing and rewinding time across DST boundaries. My basic assumption is, we are talking here about working hours so I'm inclined to go with what generally happens in business, i.e. we lose an hour in Spring and gain one in the Fall, but the latter doesn't work so well when you are in a loop!

[Intrepidd]

Closing as stale