Real fix attached to the ticket now. Reviews/comments would be much appreciated.
The fix restores the previous behavior, though I do think that behavior is a little strange/confusing. I'd expect that t.since(86400) or t.since(24.hours) would always give me exactly 24 hours past the given time, even if that crosses DST boundary. However, t.since(1.day) seems like it should give you the same time the next day (which it does). Maybe not worth breaking backward compatibility over. K On Apr 8, 1:03 pm, Ken Miller <[EMAIL PROTECTED]> wrote: > BTW, I created more unit tests to highlight a similar issue in > Time#since(): > > http://dev.rubyonrails.org/ticket/11527 > > I'm going to attempt to fix, but I'm still trying to grok the new > Duration code. > > K > > On Apr 3, 3:09 pm, Ken Miller <[EMAIL PROTECTED]> wrote: > > > Hi there, > > > In 1.2.6, tomorrow has this effect around DST: > > > >> Date.new(2007,3,11).to_time.tomorrow > > > => Mon Mar 12 00:00:00 -0700 2007 > > > In 2.0.2 (and edge) it does this: > > > >> Date.new(2007,3,11).to_time.tomorrow > > > => Sun Mar 11 23:00:00 -0700 2007 > > > The fix is pretty simple: change tomorrow (and yesterday) to use > > advance(:days => 1). I've attached the patch, which includes new > > unit tests, to an older ticket I found on the same subject. Let me > > know if it would be better to file a new one. > > >http://dev.rubyonrails.org/ticket/7399 > > > Thanks, > > Ken --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
