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

Apparently, the time zone of is GMT, but the time zone of, m, d, h, m, s) is local.

Below, I store 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 is in GMT and, m, d, h, m, s) is in local

Can anyone point me to definitive documentation about this behavior?


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

y =, x.month,, 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:

( -
=> 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: 424140856819/172800,1/24,2299161>
irb(main):021:0> y =, x.month,, x.hour, x.min,
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


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 would return the current, local
time. To me, this is against the grain of Ruby “doing what you would

I needed to compare the current time with a time stored in local time.
In order to do that, I have to capture, and then construct
a new DateTime using 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 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.


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

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


Yep, local time here also:
irb(main):001:0> require ‘date’
=> true
irb(main):002:0> puts

My findings are in agreement with yours.

If I call puts or strftime on, 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 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.


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.


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

irb(main):001:0> require ‘date’
=> true
irb(main):002:0> d =
=> #<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
=> “-08:00”


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
=> #<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:
( -

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

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

irb(main):003:0> + 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
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:

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:

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( +

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.