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???
on 2008-02-22 08:28
on 2008-02-22 09:21
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
on 2008-02-22 17:22
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 2008-02-22 18:44
Wes Gamble wrote: <snip> > 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
on 2008-02-23 16:45
On Feb 22, 12:43 pm, Justin Collins <justincoll...@ucla.edu> 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
on 2008-02-23 20:48
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
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 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) :D 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
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(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.