0

In a Rails console, I got the following:

[18] rsp(#<Job>)  »  Date.today
=> Fri, 23 Aug 2019
[19] rsp(#<Job>)  »  Date.tomorrow
=> Sun, 25 Aug 2019

Ruby supplies today while Rails supplies tomorrow

Looking at the source of tomorrow, I see that it is Date.current.tomorrow, and discover 

[21] rsp(#<Job>)  »  Date.current
=> Sat, 24 Aug 2019
[22] rsp(#<Job>)  »  Date.today
=> Fri, 23 Aug 2019

Date.current is not Date.today?

One is apparently using my current time zone, while the other one is using UTC??? Is there some rationale for this? It seems rather counterintuitive that today and tomorrow would not be parallel in this respect. Is this just an unfortunate accident based on what different design choices being made over time, or is there something else going on here, with a more logical explanation?

Is this a well-known trap that I have simply not bumped into before? Is there some standard way of making the two behave like each other to avoid such an error-prone situation?

iconoclast
  • 21,213
  • 15
  • 102
  • 138
  • 1
    This could be a time-zone issue where one is in UTC and the other is in your local time. – tadman Feb 25 '20 at 04:06
  • 1
    This is due to Rails' monkey-patching approach. They added the time-zone aware `tomorrow`and `current` methods but didn't change the built-in methods. While leaving Ruby intact is a good practice, adding method that work differently results in a half-assed `Date` class. You have to learn which methods to use and which to avoid. You might want to use `Time.zone.today` and `Time.zone.tomorrow` instead. – Stefan Feb 25 '20 at 06:04

0 Answers0