I have 3 different TimeWithZone objects:
from = Mon, 20 Apr 2020 00:00:00.000000000 UTC +00:00
to = Mon, 20 Apr 2020 23:59:59.000000000 UTC +00:00
event = Sat, 01 Jan 2000 07:00:00.000000000 UTC +00:00
I don't care about the dates. All I need is to be able to see if the time of event falls within the time bounds of from and to.
In the example above, the event does fall within the time bounds.
I've tried converting the from and to to just their time values using strftime and then converting them back to times with #to_time, but this causes the hours and minutes to change.
Any ideas?
You can format every value and than compare them
from_time, to_time, event_time = [from, to, event].map { |t| t.strftime("%H%M%S%N") }
event_time.between?(from_time, to_time)
Another option - compare just seconds (as Float)
from_sec, to_sec, event_sec = [from, to, event].map(&:seconds_since_midnight)
event_sec.between?(from_sec, to_sec)
Related
I am trying to check if a time submitted by the user in a datetime_field in a form is less than the current time.
My current issue is that the submitted date is that exact date in UTC, is Mon, 13 Apr 2020 23:00:00 UTC +00:00, however, DateTime.now.utc is 2020-04-14 03:14:00.694513 UTC.
I would like to be able to compare just the dates and the times to compare them, regardless of the timezone they are in.
I have an integer that represents a unix epoch time in millisecond precision and a time zone string. I need to create a TimeWithZone object with them.
epoch_ms_integer = 1586653140000
time_zone = "America/Los_Angeles"
Trying to convert to:
Sat, 11 Apr 2020 20:59:00 PDT -07:00
I was able to accomplish this by doing:
Time.at(epoch_ms_integer/1000).asctime.in_time_zone("America/Los_Angeles")
but was wondering if this is the best way to achieve this. The app I'm working on is configured to EST/EDT time zone so Time.at(epoch_ms_integer/1000) returns 2020-04-11 20:59:00 -0400.
I was able to find the asctime solution in one of the answers here Ruby / Rails - Change the timezone of a Time, without changing the value
the same question was asked here but no answer converting epoch time with milliseconds to datetime.
Assuming that the timestamp is in milliseconds, then 1586653140000 is
Epoch: 1586653140
GMT: Sunday, April 12, 2020 12:59:00 AM
PDT: Saturday, April 11, 2020 17:59:00 PM -in time zone America/Los Angeles
These are just 3 different ways to refer to a specific point in time around the world.
Sat, 11 Apr 2020 20:59:00 PDT -07:00 and 2020-04-11 20:59:00 -0400 each refer to different points in time and not the same as epoch(1586653140)
Since the Unix epoch (or Unix time or POSIX time or Unix timestamp) is the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT), it wouldn't make sense to take 1586653140 and only change the time zone without adding the zone's offset because now you are talking about another point in time.
To get the right "translation" from the epoch to any time zone you could just do
Time.zone = "GMT"
Time.zone.at(1586653140)
=> Sun, 12 Apr 2020 00:59:00 GMT +00:00
Time.zone = "America/Los_Angeles"
Time.zone.at(1586653140)
=> Sat, 11 Apr 2020 17:59:00 PDT -07:00
When working with dates in time zones in rails it is important to only use functions that take the set time zone into account:
DON’T USE
Time.now
Date.today
Date.today.to_time
Time.parse("2015-07-04 17:05:37")
Time.strptime(string, "%Y-%m-%dT%H:%M:%S%z")
DO USE
Time.current
2.hours.ago
Time.zone.today
Date.current
1.day.from_now
Time.zone.parse("2015-07-04 17:05:37")
Time.strptime(string, "%Y-%m-%dT%H:%M:%S%z").in_time_zone
Also keep in mind that in a Rails app, we have three different time zones:
system time,
application time, and
database time.
This post by thoughtbot explains things clearly.
I'm a bit confused about this outcome, taking today's date minus 2 months, and then taking that date again and adding two months, does not give me today's date when assign the dates to a variable.
Time.zone
"Eastern Time (US & Canada)"
> today = Date.today.in_time_zone
=> Thu, 31 Aug 2017 00:00:00 EDT -04:00
> a = today - 2.months # This is persisted to the db
=> Fri, 30 Jun 2017 00:00:00 EDT -04:00
> b = a + 2.months
=> Wed, 30 Aug 2017 00:00:00 EDT -04:00
If I however, just use the same object, it moves back and forth properly:
> today = Date.today.in_time_zone
=> Thu, 31 Aug 2017 00:00:00 EDT -04:00
> today - 2.months
=> Fri, 30 Jun 2017 00:00:00 EDT -04:00
> today + 2.months
=> Tue, 31 Oct 2017 00:00:00 EDT -04:00
The problem is obviously when "a" gets saved to a database, and then retrieved later on, and calculated plus 2 months..., it should match today's date.
TL;DR
A month is not a fixed duration. Adding or taking a month does not give the same "time shift" depending on which day you are.
The usual algorithm
to add or take months is the following :
try to land on the same day number (4th, 30th, 31st) as you started, just by changing the month
if you would land on an impossible date (like 31th September, 30th February, 29th February for some years) then just go the maximum allowed day number of this month
This implies that adding some months then taking out the same number of months will not necessarily give you back the same date.
Examples :
31st of some month + 1 month --> One would want to get to the 31th of next month
But if there is no 31st of next month (like for 31th of August, no 31st of September), then what to do ?
Usual interpretation would say that you want to go to the end of the month, this is 30th September (for rent or other monthly subscription, for instance)
But usually, 30th of some month - 1 month --> One would want to get to the 30th of the previous month.
That would lead to .... 30th of August. Not 31th of August.
Hence: some date + 1 month - 1 month does not necessarily give the original date !
Another example :
Start at the 30th of August.
Take a month -> 30th of July
Add a month -> You want to get to 30th of August (same number, next month) or to the end of August ?
The default algorithm will try to give the same day number -> 30th of August (which is more logical now)
Also with days...
Note that the same problem happens with days,but much less often ! When some days don't have the same number of hours, for daylight saving days, when adding and taking same number of days you might not get back to the original date and time as you started from.
I'm working with a Grails application and I can't find a clear way to translate a date from one TimeZone to the next/previous TimeZone available (I will define what I consider the next/previous Timezone below).
The facts:
I'm working with date filters in a Grails Application so we can retrieve information based on those filters. The application supports TimeZone so the logged user can set his profile to a particular Timezone.
The dates of the filter are on UTC format and the information on the database is stored also on UTC.
The question:
The user logged has his profile on Timezone UTC+00.
There is a predefined date filter called "This Week", when a user clicks on it generate a period of dates corresponding to the current week in UTC so we can bring all the information on the database from the current week.
If we are on the current day (Thu 19 Nov 2015) the dates the filter will generate for "This Week" to look on the database would be:
Sun Nov 15 00:00:00 UTC 2015 to Sun Nov 22 23:59:59 UTC 2015
This is correct and will bring all the information on the database on that period.
Now, suppose the user doing this has set a Timezone UTC +01.
If we are on the current day (Thu 19 Nov 2015) the dates the filter will generate to look on the database would be the same period:
Sun Nov 15 00:00:00 UTC 2015 to Sun Nov 22 23:59:59 UTC 2015
But in this case I need to translate them to a correct TimeZone because the "This Week" for the current user won't be the same for a user on UTC +01 this is because for this user the date Sun Nov 15 00:00:00 would correspond to the date
Sun Nov 14 23:00:00 on the UTC time (since he/she is one hour ahead) and therefore when filter by "This Week" I should search on the database by the dates:
Sun Nov 14 23:00:00 UTC 2015 to Sun Nov 22 22:59:59 UTC 2015
The thing is I have created a method utcDateToUserTZ(date) to translate from an UTCDate to LocalTimeZone date but this would convert the UTC dates:
Sun Nov 15 00:00:00 UTC 2015 to Sun Nov 22 23:59:59 UTC 2015
into
Sun Nov 15 01:00:00 UTC 2015 to Sun Nov 23 00:59:59 UTC 2015
And that is not what I'm looking for. I need those dates to be translated to the previous TimeZone.
I hope no to be walking around with an issue that has a simpler solution, in which case I hope you can tell me if there exist something easier to solve this.
Thanks,
The method commented before is:
public DateTime utcDateToUserTZ(Date date) {
TimeZone profileTimeZone = getCurrentUserProfile().timeZone
DateTimeZone dateTimeZone = DateTimeZone.forTimeZone(profileTimeZone)
return new DateTime(date, dateTimeZone).withZone(dateTimeZone)
}
I'm working on a Rails app where I need to find the Daylight Saving Time start and end dates given a specific offset or timezone.
I basically save in my database the timezone offset received from a user's browser( "+3", "-5") and I want to modify it when it changes because of daylight saving time.
I know Time instance variables have the dst? and isdst methods which return true or false if the date stored in them is in the daylight saving time or not.
> Time.new.isdst
=> true
But using this to find the Daylight Saving Time beginning and end dates would take too many resources and I also have to do it for each timezone offset I have.
I would like to know a better way of doing this.
Ok, building on what you've said and #dhouty's answer:
You want to be able to feed in an offset and get a set of dates for knowing if there is a DST offset or not. I would recommend ending up with a range made of two DateTime objects, as that is easily used for many purposes in Rails...
require 'tzinfo'
def make_dst_range(offset)
if dst_end = ActiveSupport::TimeZone[offset].tzinfo.current_period.local_end
dst_start = ActiveSupport::TimeZone[offset].tzinfo.current_period.local_start
dst_range = dst_start..dst_end
else
dst_range = nil
end
end
Now you have a method that can do more than just take an offset thanks to the sugar that comes with ActiveSupport. You can do things like:
make_dst_range(-8)
#=> Sun, 08 Mar 2015 03:00:00 +0000..Sun, 01 Nov 2015 02:00:00 +0000
make_dst_range('America/Detroit')
#=> Sun, 08 Mar 2015 03:00:00 +0000..Sun, 01 Nov 2015 02:00:00 +0000
make_dst_range('America/Phoenix')
#=> nil #returns nil because Phoenix does not observe DST
my_range = make_dst_range(-8)
#=> Sun, 08 Mar 2015 03:00:00 +0000..Sun, 01 Nov 2015 02:00:00 +0000
Today happens to be August 29th so:
my_range.cover?(Date.today)
#=> true
my_range.cover?(Date.today + 70)
#=> false
my_range.first
#=> Sun, 08 Mar 2015 03:00:00 +0000
#note that this is a DateTime object. If you want to print it use:
my_range.first.to_s
#=> "2015-03-08T03:00:00+00:00"
my_range.last.to_s
#=> "2015-11-01T02:00:00+00:00"
ActiveSupport gives you all sorts of goodies for display:
my_range.first.to_formatted_s(:short)
#=> "08 Mar 03:00"
my_range.first.to_formatted_s(:long)
#=> "March 08, 2015 03:00"
my_range.first.strftime('%B %d %Y')
#=> "March 08 2015"
As you can see it's completely doable with just the offset, but as I said, offset doesn't tell you everything, so you might want to grab their actual time zone and store that as a string since the method will happily accept that string and still give you the date range. Even if you are just getting the time offset between your zone and theirs, you can easily figure correct that to the UTC offset:
my_offset = -8
their_offset = -3
utc_offset = my_offset + their_offset
What you are probably looking for is TZInfo::TimezonePeriod. Specifically, the methods local_start/utc_start and local_end/utc_end.
Given a timezone offset, you can get a TZInfo::TimezonePeriod object with
ActiveSupport::TimeZone[-8].tzinfo.current_period
Or if you have a timezone name, you can also get a TZInfo::TimezonePeriod object with
ActiveSupport::TimeZone['America/Los_Angeles'].tzinfo.current_period