Strange behavior formatting moment.js date - javascript

We are tracking down a bug in our application that seemingly is related to moment.js formatting.
Here's the problematic call (reproduced in Chrome, FF, and Edge, for reference):
moment('2016-03-13T23:59:59.999-06:00').format('YYYY-MM-DD')
What we expect:
2016-03-13
What we get:
2016-03-14
This seemingly has something to do with daylight savings time as this is the only date (so far) that we've been able to reproduce this incorrect behavior on and DST flipped on that day.
If we switch the UTC offset to -05:00 then it works properly.
Here's a simple JSBIN to demonstrate
What's going on here? How can we address this?

Moment will convert a date with an offset to the local time zone of the computer that you are on, if you use the default moment constructor function.
For this reason, your code is working as expected. The date is taken from -6 and converted to your local offset.
If you want to use the date in the timezone offset specified, use moment.parseZone:
moment.parseZone('2016-03-13T23:59:59.999-06:00').format()
"2016-03-13T23:59:59-06:00"
If you want to ignore the timezone offset, and work in local time, specify a format that does not include the offset. By doing this, you cause the offset to be ignored.
moment('2016-03-13T23:59:59.999-06:00', 'YYYY-MM-DDTHH:mm:ss.SSS').format()
"2016-03-13T23:59:59-05:00"
Note that I am in UTC-5 and the offset is displayed as -5 because I ignored the offset in the date.
The parsing guide may be of some help:
http://momentjs.com/guides/#/parsing/

In the momentjs documentation regarding parsing with time zones, they show that in order to take into account the specified time zone in the input string you should be using moment.parseZone().
console.log(moment.parseZone('2016-03-13T23:59:59.999-06:00').format('YYYY-MM-DD'));
<script src="https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.12.0/moment.min.js"></script>
The above output "2016-03-13" on the console for me.

You are specifying a time zone on encoding (-6) yet are relying on the client time zone for formatting. The difference is the culprit.

Basically there's nothing wrong with the moment's format function.
console.log(moment.utc('2016-03-13T23:59:59.999-06:00').toString());
console.log(moment('2016-03-13T23:59:59.999-06:00').toString());
If you try to execute both of the above lines, you'll see that moment.utc() basically takes off the offset and converts it to the UTC time note the time, not just the date and moment() translates -06:00 offset to your local timezone and if you have smaller offset, you basically get the wrong date, because of the time.
Hope I helped.

Related

Moment js utc() time in london - BST

I'm using momentjs lib to updated text on some ajax action. What I need to do is to set a current date & time in london. I'm using moment.utc() function but because of the summer time I'm one hour out.
For example running this on 14:26
console.log( moment.utc().format('HH:mm:ss') );
I'm getting 13:26:53.
Any idea on how to fix this?
Can you use momentJS timezone?
moment().tz('Europe/London');
EDIT: In case you try to use this without seeing the link, it's a separate library you have to include.
If you want the local time instead of the UTC time, just use moment() instead of moment.utc(). You're specifically asking for UTC, so you shouldn't be surprised when you get UTC :)
From the documentation:
By default, moment parses and displays in local time.
If you want to parse or display a moment in UTC, you can use moment.utc() instead of moment().
This brings us to an interesting feature of Moment.js. UTC mode.
While in UTC mode, all display methods will display in UTC time instead of local time.
This is assuming you always want the user's local time. If you want a specific time zone (London) which may not be the user's time zone and isn't UTC, then you should use the library indicated by Takuya's answer. I would think carefully before doing so though - while it may be a sensible approach, you should at least validate that first. It's often reasonable to display a time for user U1 in the time zone of user U2 - but here you're using a fixed time zone. That's only appropriate if you know that U2 will always be in London. It would be really confusing if actually U2 is in some other zone - either the same as or different to U1.

Is there a simple time to get a timezone from a given time?

I need to get a timezone from a time, date is not important, but daylight savings is.
something like:
timezone = function("15:00");
Is there a simple way to do this?
I dont think you can get the timezone from the time but you might get some help from Date.prototype.getTimezoneOffset()
The getTimezoneOffset() method returns the time-zone offset from UTC,
in minutes, for the current locale.
Example:
var x = new Date();
var currentTimeZoneOffsetInHours = x.getTimezoneOffset() / 60;
No, of course not. Think about it, you're passing 15:00 to that function, presumable denoting it's 3PM. But in what timezone is it 3 PM? No way of knowing. It's like me saying it's quarter to, without saying what hour it's quarter to to.
The only way you can get a timezone in JS is by using the Date object, but that just shows the timezone of the machine on which your code is running, nothing about the TZ that "created" the time you're processing.
Also note that daylight saving isn't a global phenomenon, quite the contrary. AFAIKT, there isn't a single time-zone where DST has always been in place...
In order to get TimeZone information you need more than a Date (and an offset). You need a location.
Javascript does not know the location that it resides in but it does know the current offset from UTC. That is different than a Time Zone. The daylight savings time issue play havoc with this key difference.
This has posed problems when dealing with server applications that know their timezone and report dates as being in a specific Time Zone.
My rule of thumb has been fairly simple in this regard.
Always use Long or long (a 64 bit number) to store, pass and process dates times or intervals, only convert to Date, Calendar or DateTime objects when interacting with people.
Once you have a date object, such as with new Date(), you can use .getTimezoneOffset() to get the number of minutes between the date's object and UTC, which is timezone information you can use.

Convert timestamp with specified offset for timezone with Date();

I've been digging through as many things as I can find, and I can't seem to find what it is I am looking for, so I am coming to the conclusion that I either don't know what I am looking for or its not possible. Either way..
What I am trying to achieve is taking a timestamp example: 1373439600000 and a given offset of -12 to 12 (is that correct, as far as range goes?) so I can then take that timestamp above subtract from it accordingly, and pass that new timestamp to the Date() function so I can then manipulate it for human readable display.
The offset is two part, It is user specified in one instance while in the other it is going to default to the local getTimezoneOffset() if not specified. So trying to figure out how to take that range and work with that. To do everything accordingly.
Ideas? Am I even approaching this in a correct manor?
The timestamps I am working with are already UTC, not sure of that makes a difference.
The JavaScript Date type has many problems, but one of its major quirks is that it only understands two time zones - UTC, or Local. It uses UTC internally and in certain properties and functions like .toUTCString(), but otherwise it uses the local time zone.
Many browsers will accept an offset when parsing a Date from a string, but that will just be used to set the UTC time. Anything on the way out will be converted back to the local time zone again.
Fortunately, there are some great libraries out there for working around these problems. Moment.js is perfectly suited for this. Here is an example of what you might be looking for:
moment(1373439600000).zone(8).format("YYYY-MM-DD HH:mm:ss Z")
// output: "2013-07-09 23:00:00 -08:00"
Of course, you can format as needed, or pass in a more complex zone offset like "+05:30". And if you need to use an actual IANA time zone, there is the moment-timezone companion project, which you could do something like this:
moment(1373439600000).tz('America/New_York').format("YYYY-MM-DD HH:mm:ss Z")
// output: "2013-07-10 03:00:00 -04:00"
Unfortunately the Date object does not provide may facilities for working with timezones. If you have the offset though, you should be able to compute the offset in milliseconds. Then you can add (subtract?) that value to your timestamp and use it to construct the appropriate Date.
Does that help?

Javascript Date - how to know whether DST is in effect in a given timezone

First off, I am NOT looking for whether DST is in effect locally.
I'm running a Node process that has data that has associated timestamps. I need to convert those timestamps to a day/month/year in a specified time zone, but all I'm given is the time zone's offset and DST offset.
I wish Date / Moment worked better with time zones. They work great with UTC or Local time zones, but it seems you need to hack it to get something else.
Is there something I'm missing? Assuming I can determine whether DST is in effect, would this work:
var d = new Date(ts + timezone_offset - local_offset);
d.getMonth();
d.getDate();
where timezone_offset is the time zone's offset (either the standard offset or the dst one)?
How might I determine whether DST is in effect?
First, recognize that if all you have are the offsets, you cannot solve this problem. You must have a time zone identifier, such as "America/New_York". Since in the question comments you said you do indeed have this, then you can use one of these libraries to get the job done.
I had previously posted another answer to this question, recommending TimeZoneJS, but I'll retract that now - as this question is specifically about DST, and TimeZoneJS has bugs, reporting values incorrectly near DST transitions.
Instead, I'll now recommend using moment.js with the moment-timezone add-on. Once installing both libraries (being sure to load actual time zone data, per the docs), the code is quite simple:
moment(timestamp).tz(timezone).isDST()
For example:
moment(1451624400000).tz('America/New_York').isDST(); // false
moment(1467345600000).tz('America/New_York').isDST(); // true
Or, if your timestamps are already strings in terms of the local time, then use this syntax instead:
moment.tz('2016-01-01T00:00:00','America/New_York').isDST(); // false
moment.tz('2016-07-01T00:00:00','America/New_York').isDST(); // true
Is there something I'm missing? Assuming I can determine whether DST is in effect, would this work where timezone_offset is the requested time zone's offset?
Try to always use the UTC methods to get attributes of dates. That way your (server's) local timezone will not affect any calculations:
var d = new Date(ts + timezone_offset);
d.getUTCMonth();
d.getUTCDate();
How might I determine whether DST is in effect?
That's complicated. There are/were many different algorithms to determine DST beginning and end, depending on the region - have a look at http://en.wikipedia.org/wiki/Daylight_saving_time_by_country for example.
I don't know whether there are any libraries that have already coded these, or maybe even contact the timezone database for correct information. The last resort would be to ask the user himself for timezone details.
moment.js (http://momentjs.com/) has a isDST function. You could use moment (lots simpler), or check how it is implemented.
moment(your_date).isDST();

ExtJS dates and timezones

I have a problem with the Ext Date class seemingly returning the wrong timezone for a parsed date. Using the code below I create a date object for the 24th May, 1966 15:46 BST:
date = "1966-05-24T15:46:01+0100";
var pDate = Date.parseDate(date, "Y-m-d\\TH:i:sO", false);
I then call this:
console.log(pDate.getGMTOffset());
I am expecting to get the offset associated with the orignal date back (which is GMT + 1), but instead I get the local timezone of the browser instead. If the browser is set to a timezone far enough ahead GMT, the day portion of the date will also be rolled over (so the date will now appear as 25th May, 1966).
Does anyone know how to get around this and get Ext to recognise the correct timezone of the parsed date rather than the local browser timezone?
If this is not possible, can Ext be forced to use GMT rather than trying to interpret timezones?
I checked the parseDate() implementation in ExtJS source code and the documentation of Date in core JavaScript, the Date() constructor used by ExtJS does not support time zone information. JavaScript Date objects represent a UTC value, without the time zone. During parsing in ExtJS source code, the time zone is lost while the corresponding offset in minutes/seconds is added to the Date.
I then checked the source code of getGMTOffset() defined by ExtJS: it builds a time-zone string using the getTimezoneOffset() function defined in JavaScript.
Quoting the documentation of getTimezoneOffset():
The time-zone offset is the difference
between local time and Greenwich Mean
Time (GMT). Daylight savings time
prevents this value from being a
constant.
The time-zone is not a variable stored in the Date, it is a value that varies according to the period of the year that the Date falls in.
On my computer, with a French locale,
new Date(2010,1,20).getTimezoneOffset()
// -60
new Date(2010,9,20).getTimezoneOffset()
// -120
Edit: this behavior is not specific to Date parsing in ExtJS, the following note in the documentation of Date.parse() on Mozilla Doc Center is relevant here as well:
Note that while time zone specifiers
are used during date string parsing to
properly interpret the argument, they
do not affect the value returned,
which is always the number of
milliseconds between January 1, 1970
00:00:00 UTC and the point in time
represented by the argument.
I'm a little late but in latest ExtJS, you can pass an optional boolean to prevent the "rollover" in JS
http://docs.sencha.com/ext-js/4-0/#!/api/Ext.Date-method-parse
My two cents, because I can't really set all my time to 12:00 like Tim did. I posted on the sencha forum

Categories

Resources