Say this is the current server time in UTC 2021-07-30 00:33:25 UTC, which in local time is just 2021-07-29 5:33 PM
25 hours from that time is 2021-07-31 01:33:25 UTC, which in local time is 2021-07-30 6:33 PM
The stored time being compared is saved as 2021-07-30T19:00:00+00:00, which in local time should be 2021-07-30 7:00 PM
The problem is that the stored time should be 2021-07-31T02:00:00+00:00 to equal 2021-07-30 7:00 PM,
but I'm not sure of the best approach to get that time.
Here's how I get the time being sent to my rails backend
import * as moment from 'moment-timezone';
...
const start_time = moment
.tz(
listingAvailability.listing_availability_ranges_attributes[0]
.start_time,
'YYYY-MM-DD hh:mm a'
)
.tz('America/Phoenix')
.toISOString(true)
I fixed it with
moment.utc(moment(listingAvailabilityTime).utc().local()).format();
Related
I have a Date Time(Friday, 27 October 2017 4:00:00 AM) in US Central Time zone (CDT). I want to convert this Date Time into different time zones. These are time zones i wanted to convert.
Eastern Time (EDT)
Pacific Time (PDT)
New Delhi, India (IST)
Central Europian Time (CET)
Riyadh, Saudi Arabia (AST)
Pakistan Standard Time (PKT)
Lagos, Nigeria (WAT)
Australian Standard Time (AET)
Greenwich Mean Time (GMT)
Moscow, Russia (MSK)
China Standard Time (CST)
This is how i am doing
var dateTime = moment.tz("2017-10-27 4:00:00 AM", "America/Chicago");
var IST = dateTime.tz('Asia/Calcutta').format('MMMM Do YYYY, h:mm:ss a');
console.log(IST) // October 27th 2017, 9:30:00 am
The returned Date Time is wrong. Because Indian Standard Time is 10 hours and 30 minutes ahead of Central Time.
It should be Friday, 27 October 2017 2:30 PM (IST)
Thanks!
The problem isn't with the conversion to the Indian time zone - it's the original parsing of the Chicago time.
This:
var dateTime = moment.tz("2017-10-27 4:00:00 AM", "America/Chicago");
... is treated as 4am UTC, and then converted to America/Chicago, so it ends up representing 11pm local time (on October 26th) in Chicago. You can see that by just logging the value of dateTime.
If you change the code to:
var dateTime = moment.tz("2017-10-27 04:00:00", "America/Chicago");
... then it's treated as 4am local time on the 27th, which is what I believe you expected. The result of the conversion to Asia/Calcutta is then 2:30pm as you expected.
So either change the format of your input, or specify that format. For example, this works fine too:
var dateTime = moment.tz("2017-10-27 4:00:00 AM", "YYYY-MM-DD h:mm:ss a", "America/Chicago");
Using the tz() function from moment-timezone as follow:
moment.tz('2017-10-15 13:53:43','Asia/Hong_Kong').format()
//returns '2017-10-15T13:53:43+08:00'
moment.tz('2017-10-15 13:53:43','Asia/Hong_Kong').format('h:m A')
//I expect to return '9:53 PM' but it returns '1:53 PM'
Ultimately, I want to apply the fromNow() function to format the result. But when I apply it, it uses the initial timestamp and ignore the timezone applied.
moment.tz('2017-10-15 13:53:43','Asia/Hong_Kong').fromNow()
//I expect to return '1 min ago' when actual time is 13:54 UTC (21:54 in HK) but it returns '8 hours ago'
What am I doing wrong here?
When you do:
moment.tz('2017-10-15 13:53:43','Asia/Hong_Kong');
You're creating a date/time that corresponds to October 15th 2017, at 1:53 PM in Hong Kong - which, in turn, corresponds to 2017-10-15T05:53:43Z (5:53 AM in UTC).
When you call the format() function:
moment.tz('2017-10-15 13:53:43','Asia/Hong_Kong').format();
It returns:
2017-10-15T13:53:43+08:00
The +08:00 part is just the UTC offset - it just tells that Hong Kong is 8 hours ahead UTC. But 2017-10-15T13:53:43+08:00 (1:53 PM in Hong Kong) is exactly the same instant as 2017-10-15T05:53:43Z (5:53 AM in UTC). That's why fromNow(), when the current time is 13:54 UTC, returns 8 hours.
If you want the date/time that corresponds to 1:53 PM in UTC, you should use the utc() function:
// October 15th 2017, 1:53 PM in UTC
moment.utc('2017-10-15 13:53:43');
Now, when the current time is 13:54 UTC, fromNow() will return 1 minute (because the date/time represents 1:53 PM in UTC).
To convert this to Hong Kong timezone, just use the tz() function:
// convert 1:53 PM UTC to Hong Kong timezone (9:53 PM)
moment.utc('2017-10-15 13:53:43').tz('Asia/Hong_Kong').format('h:m A');
This will convert 1:53 PM UTC to Hong Kong timezone (resulting in 9:53 PM):
I'm having a frustrating issue that I can't seem to narrow down. I have searched many similar articles but they are not close enough to my issue to resolve. I am trying to pull a time from the database and display it in more than one time zone. My Rails app is using UTC as default. Here is what I'm doing:
On the create action I take the string of time which will be saved in the time column in my DB:
params[:schedule][:start] = "09:00"
Time.zone = "Central Time (US & Canada)"
#schedule.start = Time.zone.parse(params[:schedule][:start])
The above formats the time as it is supposed to:
2016-04-12 09:00:00 -0500
This is saved in the DB as:
2000-01-01 14:00:00
This has no time offset which is fine since I know it's in UTC. The problem happens when I go to display the time:
#schedule.start.in_time_zone("Central Time (US & Canada)")
This returns:
Sat, 01 Jan 2000 08:00:00 CST -06:00
Now, since this is a time column, I don't care about the date. I plan on formatting the value to only show the time. However, it is showing CST when it is currently CDT.
I can't figure out why this is happening. As I said I am not setting the Time Zone anywhere in my application.rb or anywhere else and I only set the Time zone on the create action which should be fine when moving to a new action.
Any help on clarifying this would be awesome!
This seems to be because when the time is stored it is stored with the date in the year 2000-01-01 which seems to be why it is using CST. How can I ignore the date when converting it to a particular timezone or will I need to change the column type to DateTime to get this to work properly?
It is showing CST simply because the time is read from the database including the stored date, i.e. it's read as 09:00 of Jan 1st 2000.
I guess you'd have to parse the time upon reading the attribute back. You can use a helper method in your model, for example:
# schedule model
def start_in_zone(zone)
self.start.strftime("%H:%M").in_time_zone(zone)
end
This will take only the hours and minutes part of the stored time and parse it in the given time zone with the date set to today. See this example:
"Sat, 01 Jan 2000 08:00:00".to_time.
strftime("%H:%M").
in_time_zone("Central Time (US & Canada)")
# => Tue, 12 Apr 2016 08:00:00 CDT -05:00
The fact that it matters whether it's CST or CDT means you do, on some level, care about the date. While I'm not familiar with the exact rules of Daylight Savings in that region, I do know that Jan 1 is the middle of winter and will definitely not be on Daylight Savings time.
Add the relevant date into your #schedule before putting it into a time zone, and it should fix the problem.
How do I get the number of milliseconds, in UTC time, since the epoch?
Just like myDate.getTime() returns the milliseconds in local time, I need this in universal (UTC) time.
Any ideas?
The ActionScript 2 Date object has a getTimezoneOffset method that will give you the difference between UTC and the local timezone in minutes.
var utc = myDate.getTime() + (myDate().getTimezoneOffset() * 60000);
My app is working in "Moscow" (+04:00) timezone. But sometimes I need to create time object by only local time (for example "01 may 2012 13:45") and name of ActiveSupport::TimeZone object (for example "Berlin": +02:00 in Summer Time and +01:00 otherwise).
For example if I get "01 may 2012 13:45" and "Berlin" as input I want to yield "2012-05-01 13:45:00 +0200" or "2012-05-01 11:45:00 +0000". I create following function:
def from_local_datetime(local_datetime, time_zone)
offset = Time.now.in_time_zone(time_zone).formatted_offset
datetime = case local_datetime
when String
DateTime.parse(local_datetime)
else
DateTime.new(local_datetime)
end.change(:offset => offset)
return datetime
end
And at the first look it works as I expected. But is it a best practice for this kind of task? May be in some situation It works with errors. I'm not definitely sure.
I would be greatful to any comments.
UPD: I think bug may occur about time when DST changing the time. For example 26 march 2011 was GMT+1 in Berlin time zone and Time.now.in_time_zone("Berlin").formatted_offset returns "GMT+1", but it would be GMT+2 in 27 march 2011. So if I call from_local_datetime("28 march 2011", "Berlin") before 27 march it returns 28 march 2011 00:00:00 +0100, but If I call it after changing the time my function returns 28 march 2011 00:00:00 +0200 :(
Your conversion method is the right approach.
With web sites, you should make sure times are stored as UTC in the database. If you can get the UTC value out of the database, instead of the local time (or maybe you can set your web server's time zone to UTC) it won't have to convert the time from UTC to local time, when you are going to then convert it to the user's timezone anyway.
And, of course, you will have to store the user's time zone preference.
TZInfo::Timezone.get('Europe/London')
Find the time zone
http://api.rubyonrails.org/classes/ActiveSupport/TimeZone.html