This could introduce subtle "bugs" (perceived inconsistencies), like the following:
>> Time.zone.parse('Tue, 01 Aug 2017 00:00:00 CEST +02:00') < Date.new(2017,8,1)
=> true
It seems as if Rails converts the Date to a DateTime or TimeWithZone object with '00:00:00 UTC', hence the result. Like this:
>> Date.new(2017,8,1).to_datetime
=> Tue, 01 Aug 2017 00:00:00 +0000
That would explain it. But I would like to know how Rails actually does this, and what type of object it converts it to in the process, to be sure. I didn't find it in the API docs, or the source, but maybe someone can give a step by step explanation.
The source I looked through was: compare_with_coercion
PS: To me it would seem saner that in this type of comparison that Rails would actually convert the TimeWithZone object to a Date object instead, thus resulting in only the date portions to be compared, so that:
>> Time.zone.parse('Tue, 01 Aug 2017 00:00:00 CEST +02:00') == Date.new(2017,8,1)
=> true
Ref:
DateTime API doc
Date API doc
I was playing time arithmetic in rails console. I have subtracted two different times and got back a long number, please see below my code.
a = User.find(1).updated_at # returns Mon, 03 Mar 2014 11:07:43 UTC +00:00
b = User.find(1).created_at # returns Mon, 03 Mar 2014 08:36:50 UTC +00:00
a - b # returns 9053.699814796448
My question is. What is this number 9053.699814796448? Is it time? What is it's unit? and how is that calculated? Is it possible to change the default unit of the outcome?
Thanks
a - b gives you the time in seconds. Check out the Time#- .
Today I was trying something out in my Rails console and this happened,
2.0.0p247 :009 > Date.today -29.days
=> Fri, 07 Feb 2014
2.0.0p247 :010 > Date.today - 29.days
=> Thu, 09 Jan 2014
I am pretty baffled. I can see that I am missing something basic. But it just inst striking my mind! Could anyone explain why this is happening?
What actually happens is this:
Date.today(-29.days) # => Fri, 07 Feb 2014
today has an optional parameter called start, which defaults to Date::ITALY.
An optional argument the day of calendar reform (start) as a Julian
day number, which should be 2298874 to 2426355 or -/+oo. The default
value is Date::ITALY (2299161=1582-10-15).
Passing -29.days to today apparently has no effect.
Whereas:
Date.today + -29.days # => Thu, 09 Jan 2014
Which is the same as:
Date.today - 29.days # => Thu, 09 Jan 2014
The Fixnum#days method in Ruby is defined in the ActiveSupport library in Rails. More specifically, it's defined in the 'active_support/core_ext/numeric/time` module
Just loading ActiveSupport inside a console
> require 'active_support'
true
> require 'active_support/core_ext'
true
> 29.days
=> 2505600
> -29.days
=> -2505600
The code for the method days looks like this:
def days
ActiveSupport::Duration.new(self * 24.hours, [[:days, self]])
end
The self object in this case is 29 or -29. That gets multiplied by 2505600 which is a legitimate calculation and will return the amount of seconds that the number 29 represents.
With that in mind, in the first calculation, you're just passing two objects to the console input, the first one being a Date object and the second one being a number. Similar to sending the following:
> puts "test"
That is, the -29.days is passed as an argument to the object returned byDate.today. And Date.today accepts a parameter which specifies the start day of the calendar. Refer to this answer to know the accepted days. If any non-recognized parameter is passed, the default start date is used (which is Date::GREGORIAN)
> Date.today
=> Thu, 09 Feb 2014
> Date.today Date::JULIAN
=> Fri, 25 Jan 2014
So Ruby checks if you passed in a valid start date constant or not and the decide on the start date. For this reason, you still get today's date as the answer when running the first command.
The second command is simply the subtraction of one Date object with another object that is understood by Ruby as the number of seconds you want to subtract from today's date. 29.days is internally converted to the number of seconds in both cases.
Hope that helps.
The user inputs a date range let's say from yesterday with any timezone.
from_datetime = "10/01/2012 00:00 +0545"
I get purchased time for the book like below:
purchased_at = Book.where("created_at > #{from_date}").purchased_at
=> Fri, 08 Jun 2012 09:44:26 UTC +00:00
The problem is this gives me UTC time but I want to show the purchased_at time in the requested time_zone which can vary.
I can't use in_time_zone as the input from_date only has time offset, can I ?
purchased_at.in_time_zone("Kathmandu")
=> Fri, 08 Jun 2012 15:29:26 NPT +05:45
Is there any way around?
Give an offset, you can get a timezone name from ActiveSupport::TimeZone:
> ActiveSupport::TimeZone[5.hours + 45.minutes]
=> (GMT+05:45) Kathmandu
Then you can hand that to in_time_zone:
> Time.now.in_time_zone(ActiveSupport::TimeZone[5.hours + 45.minutes])
=> Thu, 18 Oct 2012 12:33:12 NPT +05:45
You can pull the offset out of the from_datetime with a bit of simple wrangling if you know the incoming format.
There are issues with this approach:
The mapping from offset to name isn't unique.
DST could be a problem if ActiveSupport::TimeZone[] gives you the wrong name.
Depending on your needs, you could just apply the offset manually and ignore the timezone when formatting the timestamp:
> (Time.now.utc + 5.hours + 45.minutes).strftime('%Y-%m-%d %H:%M:%S +0545')
=> "2012-10-18 12:40:12 +0545"
I have a variable foo that contains a time, lets say 4pm today, but the zone offset is wrong, i.e. it is in the wrong time zone. How do I change the time zone?
When I print it I get
Fri Jun 26 07:00:00 UTC 2009
So there is no offset, and I would like to set the offset to -4 or Eastern Standard Time.
I would expect to be able to just set the offset as a property of the Time object, but that doesn't seem to be available?
You don't explicitly say how you get the actual variable but since you mention the Time class so I'll assume you got the time using that and I'll refer to that in my answer
The timezone is actually part of the Time class (in your case the timezone is shown as UTC). Time.now will return the offset from UTC as part of the Time.now response.
>> local = Time.now
=> 2012-08-13 08:36:50 +0000
>> local.hour
=> 8
>> local.min
=> 36
>>
... in this case I happen to be in the same timezone as GMT
Converting between timezones
The easiest way that I've found is to change the offset using '+/-HH:MM' format to the getlocal method. Let's pretend I want to convert between the time in Dublin and the time in New York
?> dublin = Time.now
=> 2012-08-13 08:36:50 +0000
>> new_york = dublin + Time.zone_offset('EST')
=> 2012-08-13 08:36:50 +0000
>> dublin.hour
=> 8
>> new_york.hour
=> 3
Assuming that 'EST' is the name of the Timezone for New York, as Dan points out sometimes 'EDT' is the correct TZ.
This takes advantage of the fact that Time#asctime doesn't include the zone.
Given a time:
>> time = Time.now
=> 2013-03-13 13:01:48 -0500
Force it to another zone (this returns an ActiveSupport::TimeWithZone):
>> ActiveSupport::TimeZone['US/Pacific'].parse(time.asctime)
=> Wed, 13 Mar 2013 13:01:48 PDT -07:00
Note that the original zone is ignored completely. If I convert the original time to utc, the result will be different:
>> ActiveSupport::TimeZone['US/Pacific'].parse(time.getutc.asctime)
=> Wed, 13 Mar 2013 18:01:48 PDT -07:00
You can use to_time or to_datetime on the result to get a corresponding Time or DateTime.
This question uses an interesting approach with DateTime#change to set the tz offset. (Remember that ActiveSupport makes it easy to convert between Time and DateTime.) The downside is that there's no DST detection; you have to do that manually by using TZInfo's current_period.
If given:
2011-10-25 07:21:35 -700
you want:
2011-10-25 07:21:35 UTC
then do:
Time.parse(Time.now.strftime('%Y-%m-%d %H:%M:%S UTC')).to_s
...
>> Time.at(Time.now.utc + Time.zone_offset('PST'))
=> Mon Jun 07 22:46:22 UTC 2010
>> Time.at(Time.now.utc + Time.zone_offset('PDT'))
=> Mon Jun 07 23:46:26 UTC 2010
>> Time.at(Time.now.utc + Time.zone_offset('CST'))
=> Tue Jun 08 00:46:32 UTC 2010
One note: make sure that the current time object is set to UTC time first, otherwise Ruby will try and convert the Time object to your local timezone, thus throwing the calculation. You can always get the adjusted time by applying ".utc" to the end of the above statements in that case.
For those that came across this while looking for a non-rails solution (as I did), TZInfo solved it for me...
require 'tzinfo'
def adjust_time time, time_zone="America/Los_Angeles"
return TZInfo::Timezone.get(time_zone).utc_to_local(time.utc)
end
puts adjust_time(Time.now)
#=> PST or PDT
puts adjust_time(Time.now, "America/New_York")
#=> EST or EDT
This also handles DST, which is what I needed that wasn't handled above.
See: http://tzinfo.rubyforge.org/
in you environment.rb search for the following line.
# Set Time.zone default to the specified zone and make Active Record auto-convert to this zone.
# Run "rake -D time" for a list of tasks for finding time zone names.
config.time_zone = 'UTC'
Keep in mind ActiveRecord and Rails always handle Time as UTC internally.
I'm using Rails 2.0 before they added the code that makes weppos solution work. Here's what I did
# Silly hack, because sometimes the input_date is in the wrong timezone
temp = input_date.to_time.to_a
temp[8] = true
temp[9] = "Eastern Daylight Time"
input_date = Time.local(*temp)
I break the time down into a 10 element array, change the timezone and then convert the array back into a time.
Here is what worked for me...
def convert_zones(to_zone)
to_zone_time = to_zone.localtime
end
# have your time set as time
time = convert_zones(time)
time.strftime("%b #{day}, %Y (%a) #{hour}:%M %p %Z")
This is what I did, as I am not using Rails and don't want to use any non-core gems.
t = Time.now # my local time - which is GMT
zone_offset = 3600 # offset for CET - which is my target time zone
zone_offset += 3600 if t.dst? # an extra hour offset in summer
time_cet = Time.mktime(t.sec, t.min, t.hour, t.mday, t.mon, t.year, nil, nil, t.dst?, zone_offset)
Option 1
Use date_time_attribute gem:
my_date_time = DateTimeAttribute::Container.new(Time.zone.now)
my_date_time.date_time # => 2001-02-03 22:00:00 KRAT +0700
my_date_time.time_zone = 'Moscow'
my_date_time.date_time # => 2001-02-03 22:00:00 MSK +0400
Option 2
If time is used as an attribute, you can use the same date_time_attribute gem:
class Task
include DateTimeAttribute
date_time_attribute :due_at
end
task = Task.new
task.due_at_time_zone = 'Moscow'
task.due_at # => Mon, 03 Feb 2013 22:00:00 MSK +04:00
task.due_at_time_zone = 'London'
task.due_at # => Mon, 03 Feb 2013 22:00:00 GMT +00:00
It's probably a good idea to store the time as UTC and then show it in a specific time zone when it is displayed. Here's an easy way to do that (works in Rails 4, unsure about earlier versions).
t = Time.now.utc
=> 2016-04-19 20:18:33 UTC
t.in_time_zone("EST")
=> Tue, 19 Apr 2016 15:18:33 EST -05:00
But if you really want to store it in a specific timezone, you can just set the initial Time object to itself.in_time_zone like this:
t = t.in_time_zone("EST")
When Parsing a Time
I'd be interested to hear how you're setting the variable foo to begin with.
If you're parsing a time string that doesn't have a time zone (what I was doing during a data import) then you can use String#in_time_zone to force the time zone during the parsing:
"Fri Jun 26 2019 07:00:00".in_time_zone( "Eastern Time (US & Canada)" )
# => Wed, 26 Jun 2019 07:00:00 EDT -04:00
Works like a charm and is super clean.
You can do:
DateTime.parse('Fri Jun 26 07:00:00 UTC 2009').change(offset: '-0400')
Which returns:
Fri, 26 Jun 2009 07:00:00 -0400