I've been banging my head on this for over a day, gone into the source code, and this looks to be an issue with the awesome javascript moment.tz library:
Whenever I pass in a timezone identifier of "Etc/GMTtime-value", the moment.tz object returned comes back with what I believe to be an format("Z") value as it is multiplied by -1.
Example:
var pacificTime = moment.tz("2016-09-29 21:00:00","America/Los_Angeles");
pacificTime.format("YYYY-MM-DD HH:mm:ss Z z");
output: "2016-09-29 21:00:00 -07:00 PDT"
All is as expected here.
Now, using the same time zone (GMT-7):
var GMT_minus_7 = moment.tz("2016-09-29 21:00:00","Etc/GMT-7");
GMT_minus_7.format("YYYY-MM-DD HH:mm:ss Z z");
output: "2016-09-29 21:00:00 +07:00 GMT-7"
The bold faced value is always the negative value of what I believe it should be: Passing in "Etc/GMT+5" returns a "-5:00" value.
This is causing me a headache, as the web page I'm working with has records with date/time records an integer "GMT offset" value which I simply turn into "Etc/GMT" + offset_value and pass into moment.tz to do a time zone conversion. I then need to do further manipulation on the value (adding days, displaying that "Z" formatted value, etc.) but this issue has impeded further work.
Is this a defect with moment.tz parsing the "Etc/GMT" timezone values, or am I missing something fundamental about time zone formatting?
The identifiers in the IANA database such as Etc/GMT-7 have their offset inverted intentionally. This is part of the design of this style of identifier. See the note in Wikipedia on this, and in the tz database source itself. (Basically, it stems from the need to be backwards compatible with older POSIX standards in certain environments.)
However, in the case of Moment.js, you do not need to use these at all if you are working with a fixed time zone offset. In fact, you don't need the moment-timezone extension at all.
// the parseZone method will retain the offset provided
var a = moment.parseZone("2016-09-29 21:00:00 -07:00");
// or, you can set the offset explicitly like this:
var b = moment.utc("2016-09-29 21:00:00").utcOffset("-07:00", true);
// or like this if you prefer:
var c = moment.utc("2016-09-29 21:00:00").utcOffset(-7, true);
For b and c, note that the true parameter is required to retain the given local time. Also note that I use moment.utc(...) to initially parse the string. It would also work with just moment(...), but then it's possible that a DST transition in the local time zone could interfere with the interim value.
Also, make sure you recognize that America/Los_Angeles alternates between -8 and -7 depending on whether DST is in effect or not. That is why you would need moment-timezone to supply the rules for when to switch between offsets.
Related
I found a couple other posts but they didn't have something specific to what I was looking for.
Here's the scenario:
A user in China (although it could be anywhere in the world) inputs a date time into a field that represents a local time in the U.S. So even though their local machine might be 1:11 AM 02/15/2018 in Beijing, the user is entering a date in Austin, TX for 11:11 AM 02/14/2018 into the date time field.
This is the string I'm pulling from the input field:
'2018-02-14T11:11'
How can I use moment.js to make sure that when I convert '2018-02-14T11:11' to UTC, the UTC string always reflects Austin time, not Beijing time? At the end of the day, we won't know which timezone the user is from, but we will always know the entered timezone will be in Central Standard Time.
What seems to be happening with the below is that when I use these to convert to UTC, the dates are still not reflecting CST, or they are offset incorrectly by several hours.
moment('2018-02-14T11:11').zone("America/Chicago").format()
moment('2018-02-14T11:11').tz("America/Chicago").format()
moment('2018-02-14T11:11', 'CST').tz("America/Chicago").format()
moment('2018-02-14T11:11', "America/Chicago").tz("America/Chicago").format()
To UTC:
moment.utc('2018-02-14T11:11').tz("America/Chicago").toISOString()
I'm definitely missing something. Any advice would be appreciated!
Thanks in advance!
You're close - you will need the Moment-Timezone addon, and then it's like this:
moment.tz('2018-02-14T11:11', "America/Chicago").utc().format()
Let's break that down:
// create the moment with a specific time zone
var m = moment.tz('2018-02-14T11:11', "America/Chicago");
// convert to UTC
m.utc();
// format the output
var s = m.format();
Just add another scenario that I got:
Parse '2018-02-14Z', but ignore 'Z' (UTC), just use local time zone or a specified timezone.
You can simply remove 'Z' from the string or do these:
moment('2018-02-14Z', 'YYYY-MM-DD') will ignore 'Z' or any unmatched characters.
moment.tz('2018-02-14Z', 'YYYY-MM-DD', 'America/Chicago') will use the given timezone.
Of course, you should not do this in the first place. A correct timezone should be used.
I need to set a datetime-local picker's default value to the current local time. Native JS seems to output in local time by default:
new Date($.now()); // "Sat Nov 12 2016 22:36:52 GMT+1100 (AEDT)"
However functions like toISOString() output in UTC, and although I can pull out individual components locally, I don't really want to fiddle around with padding and such. So I try this using moment.js:
moment().local().format(); // "2016-11-12T22:34:05+11:00"
Cool! Now I just need to adjust the format to a tiny bit:
moment().local().format('YYYY-MM-DThh:mm'); // "2016-11-12T10:39"
Waaaaaaait. Now it's in UTC again, even though I specified local.
In this particular case I could use string manipulation to just drop the end off for the date-time picker, but surely I'm going to reach a point where I want to output the local time in an arbitrary format. Am I missing something here?
Your second example isn't UTC, it's just using 12h format.
hh = 12h, HH = 24h. Try this instead:
moment().local().format('YYYY-MM-DTHH:mm')
I'm a typically server side developer feeling a bit like a fish out of water trying to display time values on the front end. How can I get behavior like PHP's date() and strtotime() functions out of moment.js? I just want a unix timestamp to appear in H:i:s format, and vice versa.
So far I've tried the following, from existing example code and the documentation:
moment(timestamp).format(H:i:s);
moment().duration(timestamp).format(H:i:s);
moment.unix(timestamp).format(h:mm:ss);
moment(formatted,'H:i:s');
Not a SINGLE one of which has worked properly. This may get flagged as duplicate since there are plenty of moment.js questions out there, but I don't know whether it's been updates to the library itself or slightly different context, I have not found one existing solution that has worked for me.
Anybody have any suggestions for these two simple tasks?
EDIT:
I've distilled two different problems out of this. One is that functions the moment docs say should work are giving weird values:
moment(1437462000).format('h:mm:ss')
for instance, which should return 7:00:00 utc, returns 10:17:42. This can be fixed in this case by using moment.unix(1437462000).utc().format('h:mm:ss') instead, but this leads into the second problem - the .utc() function seems to get ignored when converting back from a date into a timestamp:
timestamp = moment(formatted,'DD/MM/YYYY H:m:s').utc().unix();
will still return a timezone corrected value (in my case this is incorrect by several hours since the formatted time in question has nothing to do with the client computer) regardless of whether the .utc() function is included or not.
A few things you should realize:
Unix timestamps should always in terms of UTC. They are never adjusted for time zone in numerical form. If they're adjusted for time zone, that's done during the interpretation of the number, not in its representation.
While traditionally a "Unix Timestamp" is in terms of seconds, many environments use milliseconds instead. PHP's date timestamps are based on seconds, while moment and JavaScript's Date object both use milliseconds by default. Using the moment.unix function will let you pass seconds, and is identical to just multiplying the timestamp by 1000.
Moment has two built-in modes, local and UTC. The default mode is local. It doesn't matter what input you provide, if you don't specify UTC, the moment is adjusted to local. To specify UTC, you use the utc function. There are two forms of the function:
moment.utc(input) // parsing form
moment(input).utc() // conversion form
Both forms take some input and result in a moment in UTC mode. The difference is in how the input is interpreted. In either case, if the input value is unambiguous, the result is the same. For strings, that means the input would contain either a Z (from ISO8601), or a UTC-based offset. All other forms are ambiguous. For example, if I pass "2015-11-08 01:23:45", I will get different results depending on whether I interpret that string as local time or as UTC.
For numbers, they are always interpreted as milliseconds in UTC. However, if you use moment(number) without then calling .utc() then the moment is left in local mode, so any output will display as local time.
When you call moment.unix(input), the input is a number of seconds, but the moment is left in local mode. So to display the UTC time, you would use moment.unix(input).utc().
If your pre-recorded timestamps from your other system are in numeric form, but have been adjusted away from UTC, then they are incorrect. You have bad data, and Moment can't help you unless you know specifically how they have deviated and you write code to counteract that.
Moment's formatters are case sensitive. M is months, m is minutes. H is hours on a 24-hour clock, h is hours on a 12-hour clock. Use two consecutive letters when you want to include zero-padding. Example, HH:mm:ss for 13:02:03 vs. h:m:s for 1:2:3.
Moment's X formatter does not care which mode the moment is in. It will always emit seconds in UTC. Likewise, the x formatter returns milliseconds in UTC, as does moment.valueOf().
Also, your last example:
moment.unix(1437462000).utc().format()
Returns "2015-07-21T07:00:00+00:00" - which I believe is the value you expected.
You also get the same original timestamp regardless of which of these you try:
moment.unix(1437462000).utc().format("X") // "1437462000"
moment.unix(1437462000).format("X") // "1437462000"
moment.unix(1437462000).utc().unix() // 1437462000
moment.unix(1437462000).unix() // 1437462000
For anyone who comes in and is still looking for direct PHP equivalents for date() and strtotime(), here are the ones I ended up using. Matching up to php basically means just completely ignoring any kind of local time information by making sure everything is in UTC. That task is a little different between the timestamp->date and date->timestamp cases, though, so you have to be careful.
date()
Converting a timestamp to formatted date without any client timezone correction
var formatted = moment.unix(timestamp).utc().format('h:mm:ss');
strtotime()
Converting a UTC formatted date back to a timestamp without correcting it to local time:
var new_timestamp = moment.utc(formatted_utc,'DD/MM/YYYY H:m:s').format('X')
//where 'DD/MM/YYYY H:m:s' is the formatted date's format, and
//'X' outputs a unix timestamp without milliseconds.
Notes:
Do not use moment() with parenthesis in the calls:
moment().utc(date,format) will return local time values, not your
input.
Moment.js does not like the use of 'i' for minutes in the formatting,
unlike php.
In a nutshell I want moment to respect server's timezone. I've set my machine's timezone to Alaska but I'm passing a Brisbane timezone string to moment. Now I need moment.toDate to return a date instance in the same timezone as the one I pass in the moment constructor; e.g.
m = moment("2016-11-20T08:00:00+10:00")
m.format() // "2016-11-20T08:00:00+10:00"
m.toDate() // Sat Nov 19 2016 13:00:00 GMT-0900 (AKST)
I want to get a Date instance from moment that's in the input timezone; e.g. somehow get toDate to return Sun Nov 20 2016 08:00:00 GMT+1000 (AEST).
FWIW I have tried the same code with and without moment.tz.setDefault and while it correctly changes the format result, toDate always uses the machine's timezone!
Update
The reason I need this behaviour is that some JavaScript libraries and controls don't understand moment and only work with Date and the time/date gets skewed when presented back by them. One example, the one I'm currently dealing with, is jQuery UI date picker control. I want the date picker to show the current date as it's on the server (or on a specific timezone).
Thanks in advance.
The Date object represents the time in UTC internally, and can only use the time zone of the machine its running on when projected.
There's absolutely no way to produce a Date object that uses an arbitrary time zone. Any examples you may come across that try to manipulate the Date object (such by adding or subtracting time zone offsets) are fundamentally flawed.
Moment itself has great time zone support, including the moment-timezone extension for working with named time zones instead of just time zone offsets. But once you go back to a Date object - you're back at the mercy of the behavior of that object.
Sorry, but there's no way to achieve what you are asking. Perhaps you could elaborate as to why you wanted to do this, and I could recommend a workaround.
Update: With regards to your update, usually there is a mechanism for getting the value from a date picker as text, rather than as a date object. With the example of the jQuery UI date picker control, the onSelect event gives it to you as text already, or you can simply call .val() instead of .datepicker('getDate') to get the text out of the field. Once you have a textual value, you can then parse it with moment however you like.
Similarly, when setting the value, you don't necessarily need a Date object. You could just set the value of the textbox as a string, or you can pass a string to the setDate function.
In most cases, you won't have to go through a Date object. But if for some reason you do, then you'll need to artificially construct one with something crazy like:
var d = new Date(m.format('YYYY/MM/DD'));
Normally, I'd be against that - but if it's just there to get the pass a value to a UI control, then it's probably ok.
This will get you a moment in the same timezone as the moment string, but toDate is always in the local timezone.
d = "2016-11-20T08:00:00+10:00"
m = moment(d).utcOffset(d)
m.format()
m.toDate()
Using moment.js, I'm attempting to extract the offset from an ISO date string so I can use the offset later when formatting an epoch timestamp to ensure the conversion of the timestamp is in the same timezone.
Even though the offset in the string is -0400, the result is always 0;
var currentTime = "2015-03-18T16:10:00.001-0400";
var utcOffset = moment(currentTime).utcOffset(); // 0
I've attempted to use parseZone() as well without success. Is there a way to extract -0400 from the string so I can use it while formatting another time?
Thanks for the help!
KC
The correct way to extract the offset is indeed with parseZone
var currentTime = "2015-03-18T16:10:00.001-0400";
var utcOffset = moment.parseZone(currentTime).utcOffset();
This should result in -240, which means 240 minutes behind UTC, which is the same as the -0400 in the input string. If you wanted the string form, instead of utcOffset() you could use .format('Z') for "-04:00" or .format('ZZ') for "-0400".
The form you gave in the question just uses the computer's local time zone. So it is currently UTC+00:00 in your time zone (or wherever the code is running), that would explain why you would get a zero. You have to use parseZone to retain the offset of the input string.
Also - your use case is a bit worrying. Remember, an offset is not the same thing as a time zone. A time zone can change its offset at different points in time. Many time zones do this to accommodate daylight saving time. If you pick an offset off of one timestamp and apply it to another, you don't have any guarantees that the offset is correct for the new timestamp.
As an example, consider the US Eastern time zone, which just changed from UTC-05:00 to UTC-04:00 when daylight saving time took effect on March 8th, 2015. If you took a value like the one you provided, and applied it to a date of March 1st, you would be placing it into the Atlantic time zone instead of the Eastern time zone.