I run this in console:
110.years.ago.to_datetime
=> Fri, 14 Mar 1902 01:20:12 +0000
Today is the 13th of march. So why is it returning 14th?
I run this in console:
110.years.ago.to_datetime
=> Fri, 14 Mar 1902 01:20:12 +0000
Today is the 13th of march. So why is it returning 14th?
What is your timezone? for timezone 0 is 14 =)
2012/3/13 John M. [email protected]
“Ruby on Rails: Talk” group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
–
Fernando A.
110.years.ago.to_datetime.in_time_zone(-3)
=> Thu, 13 Mar 1902 22:29:48 LMT -03:06
2012/3/13 Fernando A. [email protected]
–
Fernando A.
www.fernandoalmeida.net
–
Fernando A.
Quoting John M. [email protected]:
I run this in console:
110.years.ago.to_datetime
=> Fri, 14 Mar 1902 01:20:12 +0000Today is the 13th of march. So why is it returning 14th?
Time zones. Notice the +0000 at the end. You are in the Pacific time
zone
according to the headers in your e-mail (assuming the list server hasn’t
mangled them). So
Fri, 14 Mar 1902 01:20:12 +0000
is
Thu, 13 Mar 1902 18:20:12 -0700
Probably your Rails in configured to use UTC as the default timezone.
$ cd config/
$ grep UTC *
environment.rb: config.time_zone = ‘UTC’
environment.rb~: config.time_zone = ‘UTC’
HTH,
Jeffrey
Fernando A. wrote in post #1051362:
What is your timezone? for timezone 0 is 14 =)
Yea. Date math is way more complicated than one might originally guess.
Explains why there’s about 15 different Date and Calendar
implementations in Java and very few of them are accurate over long time
periods. I don’t really know how accurate Ruby’s implementation is.
On 15 March 2012 15:42, John M. [email protected] wrote:
There wont be a specific timezone, people will use it in all timezones
and so I would need it to work for everyone.
You are missing the point, unfortunately you seem to have broken the
thread and lost your original example, but the calculation
110.years.ago gave you /exactly/ the right answer (to the second), the
reason it looked wrong is that you were not looking at the time zone
of the answer, so at first glance it looked wrong. If you make sure
that you display the answer in the same time zone as the original then
it will be what you want.
Colin
was an invalid age even though I specify above 110 years ago is ok.
My environment is already set to UTC:
–
gplus.to/clanlaw
On Mar 15, 3:42pm, John M. [email protected] wrote:
And thats when it gives me wrong date.
My environment is already set to UTC:
config.time_zone = ‘UTC’
thanks for response
That’s why the answer was march 14th. You say that the date was march
13th 2012, but in the timezone you were doing your calculations in it
was already march 14th
Fred
There wont be a specific timezone, people will use it in all timezones
and so I would need it to work for everyone.
This issue started for me when I had this:
validates_inclusion_of :date_of_birth, :in =>
110.years.ago.to_datetime…60.years.ago.to_datetime, :message
=> :invalid_age, :allow_nil => true
So I trried to add date of birth of 110 years exactly, and it said it
was an invalid age even though I specify above 110 years ago is ok.
Then I try this:
validates_inclusion_of :date_of_birth, :in =>
(110.years.ago.to_datetime - 1.days)…
60.years.ago.to_datetime, :message => :invalid_age, :allow_nil => true
And thats when it gives me wrong date.
My environment is already set to UTC:
config.time_zone = ‘UTC’
thanks for response
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs