DateTime.new vs. DateTime.now

This may be a well known thing but it surprised me.

Apparently, the time zone of DateTime.now is GMT, but the time zone of
DateTime.new(y, m, d, h, m, s) is local.

Below, I store DateTime.now in x. Then I construct a new DateTime
object using the various components of x. You might expect that x - y
would be 0 or very close to it, but in fact it is very close to the
offset of my time zone (US Central) from GMT, which is .25 day (or 360
min if you multiply .25 day * (1440 min/day)). This implies that
DateTime.now is in GMT and DateTime.new(y, m, d, h, m, s) is in local
time.

Can anyone point me to definitive documentation about this behavior?

Thanks,
Wes

x = DateTime.now
=> #<DateTime: 212070424110293/86400000,-1/4,2299161>

y = DateTime.new(x.year, x.month, x.day, x.hour, x.min, x.sec, x.sec_fraction
)
=> #<DateTime: 212070402509707/86400000,293/86400000,2299161>

x - y
=> Rational(10800293, 43200000)

(x - y).to_f
=> 0.250006782407407

(x - y).to_f * 1440
=> 360.009766666667

y - y
=> Rational(0, 1)

P. S. Another unusual thing is this:

(DateTime.now - DateTime.new).to_f
=> 2454519.30391494

What’s that???

You forgot to set the offset parameter which is defaulted to 0. It is
a fraction of a day and represents the time added to a timezone.

irb(main):020:0> x = DateTime.now
=> #<DateTime: 424140856819/172800,1/24,2299161>
irb(main):021:0> y = DateTime.new(x.year, x.month, x.day, x.hour, x.min,
x.sec,
x.sec_fraction, x.offset)
=> #<DateTime: 424140864017/172800,1/172800,1/24>
irb(main):022:0> (x-y).to_f
=> -0.0416550925925926

The difference is probably just a float point precision error.

You can find more to new(which is aliased as civil) at
http://www.ruby-doc.org/core/classes/DateTime.html#M002822

Thomas,

Thanks for that - that helps.

I guess I should have explained the reason I even bothered to look into
this so deeply.

I really expected that DateTime.now would return the current, local
time. To me, this is against the grain of Ruby “doing what you would
expect.”

I needed to compare the current time with a time stored in local time.
In order to do that, I have to capture DateTime.now, and then construct
a new DateTime using DateTime.new with its components in order to get a
local time that I can then use to calculate the difference between my
stored time and the current time.

I’ve gotten past my problem, but it seems to me that DateTime.now should
represent local time, and if I want gmt, then I can ask for something
like DateTime.gmt.

If there is a simpler way to ask for a DateTime object that represents
the current, local time, I was unable to find it.

Wes

On Feb 22, 12:43 pm, Justin C. [email protected] wrote:

set to GMT?
=> 35
irb(main):006:0> d.sec
=> 8
irb(main):007:0> d.zone
=> “-08:00”

-Justin

Yep, local time here also:
irb(main):001:0> require ‘date’
=> true
irb(main):002:0> puts DateTime.now
2008-02-23T10:41:51-05:00

My findings are in agreement with yours.

If I call puts or strftime on DateTime.now, I will get local time.
If I call time component methods (hour, min, sec, etc.), I will get
local time.

But if I just take a DateTime.now and do math with it, it is in GMT.

I would assert that the strftime, puts, and all of the time component
methods do an implicit GMT-to-local time conversion as part of their
processing. That is the only thing that would explain the behavior that
I am seeing.

Thanks,
Wes

Wes G. wrote:

If there is a simpler way to ask for a DateTime object that represents
the current, local time, I was unable to find it.

Wes

That is precisely what I get with DateTime.now. Maybe your machine is
set to GMT?

irb(main):001:0> require ‘date’
=> true
irb(main):002:0> d = DateTime.now
=> #<DateTime: 5890846158565549/2400000000,-1/3,2299161>
irb(main):003:0> d.strftime
=> “2008-02-22T09:35:08-08:00”
irb(main):004:0> d.hour
=> 9
irb(main):005:0> d.min
=> 35
irb(main):006:0> d.sec
=> 8
irb(main):007:0> d.zone
=> “-08:00”

-Justin

An interesting problem. Ruby Date class and subclass DateTime work
together for working with time and date.

If you had only showed this:
irb(main):001:0> require ‘date’
=> true
irb(main):002:0> DateTime.new
=> #<DateTime: -4712-01-01T00:00:00+00:00 ((0j,0s,0n),+0s,2299161j)>

we could see the base date and time it begins at.

This is close to the Joseph Scaliger Julian date that he chose to
begin counting days from for the Julian date system.

The only trouble is that it is normally defined as UTC noon or
12:00:00. Your question does the correction I needed to figure out. I’m
referring to:
(DateTime.now - DateTime.new).to_f

This will give you the actual Julian date in UTC with the correct time
as a decimal of hours.

Now referring back to my problem I needed the correct base Julian
date.

I can get it by simply adding 0.5 hours on to that base date.

irb(main):003:0> DateTime.new + 0.5
=> #<DateTime: -4712-01-01T12:00:00+00:00 ((0j,43200s,0n),+0s,2299161j)>

Thanks for your post and this is still true even in new versions of
Ruby.
I don’t believe it should be that way. How about it?

I suspect that the coder had their reasons for this as the date line of
the world begins at UTC -12 hours but I can’t be sure. Anyway thanks for
solving part of my issue. Happy coding(Ruby coding that is) :smiley:

P.S. What I usually keep in mind is that you can make sure your using
UTC in the first place like so:

DateTime.now.to_time.utc.to_datetime

to be sure. That gives the correct time and date UTC for #now method.

Then if you need your time just add one more method:

DateTime.now.to_time.utc.to_datetime.to_time

One of the things I discussed in my last post was the #jd() method.
One other reason this might have been kept 12 hours out could be for
code like this:

DateTime.jd(DateTime.now.to_time.utc.to_datetime.jd +
DateTime.now.to_time.utc.to_datetime.day_fraction)

I know that it seems a little too long of a chain but I don’t think
rubocop will write you up.

“You should try to work in UTC for your log book” an old ham buddy of
mine once told me. Unfortunately without converting it to time first you
cannot change the timezone. It will calculate your machine’s setting and
then report it as UTC or +00:00 without doing so.