Forum: Ruby vs.

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
Bb4bdf2b184027bc38d4fb529770cde5?d=identicon&s=25 Wes Gamble (weyus)
on 2008-02-22 08:28
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???
88de1beaaacae26b839f2e6aebf857b6?d=identicon&s=25 Thomas Wieczorek (Guest)
on 2008-02-22 09:21
(Received via mailing list)
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
Bb4bdf2b184027bc38d4fb529770cde5?d=identicon&s=25 Wes Gamble (weyus)
on 2008-02-22 17:22

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.

6e366eb5a71be2bad7f383d42aeb4788?d=identicon&s=25 Justin Collins (Guest)
on 2008-02-22 18:44
(Received via mailing list)
Wes Gamble 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 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"

8666d1ebabcea440585dfe831a4af9f1?d=identicon&s=25 Brian Adkins (Guest)
on 2008-02-23 16:45
(Received via mailing list)
On Feb 22, 12:43 pm, Justin Collins <> wrote:
> set to GMT?
> => 35
> irb(main):006:0> d.sec
> => 8
> irb(main):007:0>
> => "-08:00"
> -Justin

Yep, local time here also:
irb(main):001:0> require 'date'
=> true
irb(main):002:0> puts
Bb4bdf2b184027bc38d4fb529770cde5?d=identicon&s=25 Wes Gamble (weyus)
on 2008-02-23 20:48
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.

02bed14d16954900634cb83771445dc0?d=identicon&s=25 Douglas Allen (kb9agt)
on 2014-11-16 02:53
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) :D

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:
02bed14d16954900634cb83771445dc0?d=identicon&s=25 Douglas Allen (kb9agt)
on 2014-11-24 04:08
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.
This topic is locked and can not be replied to.