I'm using DateJS to parse user-inputted dates, and getting some strange results.
Date.parse("15 Jan 2010") returns Fri Jan 15 00:00:00 EST 2010 (right)
Date.parse("15-Apr-2010") returns Thu Apr 15 00:00:00 EDT 2010 (right)
Date.parse("15 Apr 2010") returns Thu Apr 1 00:00:00 EDT 2010 (wrong)
As far as I can tell, the d MMM yyyy input format works fine for every month except April and August; in those two cases, it returns the first of the month no matter what day is entered. Is this a bug, or is there a logical explanation I'm missing?
Aha: Looks like the version in the "Download" link is a good bit older than the current source. Here's the commit that fixed this bug:
Dan Yoder fixed bug with timeContext pattern where if a date included
"april" or "august", the parser thought the 'a' was the beginning of a time part
(as in am/pm).
The most recent version of the EN-US script is here:
http://code.google.com/p/datejs/source/browse/trunk/build/date-en-US.js
It would be nice if the website linked to this instead of to a zip file that hasn't been updated for a couple of years.
Related
Starting Chrome 67 (full version is 67.0.3396.87), I am experiencing weird behaviour with creation of a new Date object. Smallest reproducible case, goes something like:
<html>
<body>
<script> alert(new Date(-62135596800000)); </script>
</body>
</html>
On Firefox 60.0.2 the alert message is:
Mon Jan 01 0001 00:00:00 GMT+0000 (GMT Standard Time)
On Internet Explorer 11 and Edge 41.16299.461.0, the alert message is same as Firefox:
Mon Jan 01 0001 00:00:00 GMT+0000 (GMT Standard Time)
However, on Chrome 67 I see:
Sun Dec 31 0000 23:58:45 GMT-0001 (Greenwich Mean Time)
Edit: JsFiddle
Edit2 Turns out it's nothing to do with Microsoft's library.
Depending on the response to that bug report, I think this is actually due to Chrome possibly including IANA timezone information. Browsers, time zones, Chrome 67 Error
For example, when I run that fiddle, I get Sun Dec 31 0000 18:09:24 GMT-0550 (Central Standard Time) which corresponds to the IANA entry Zone America/Chicago -5:50:36 - LMT 1883 Nov 18 12:09:24.
So this is a "feature" not a bug I think. They are using the more "accurate" historical time offsets instead of current day time offsets for historical dates.
You can view the data here : https://github.com/eggert/tz just look for your appropriate world location file and try and avoid all the commented out lines unless you are morbidly curious about the history of your time zones.
What you can do to "fix" it so it display more or less correctly is to call .toUTCString() on the Date object which will force it to UTC time and display Mon, 01 Jan 0001 00:00:00 GMT as #Pointy pointed out in the comments on the initial question.
Your code, as long as MS's one, doesn't know anything about the timezone, so I assume Chrome takes the default one.
I guess it should be better if you create your date as below:
const date = new Date(Date.UTC(year, month, day, hour, minute, second));
Please see the code example below from Google Chrome:
new Date('Thu Jul 27 2017 13:10:42 GMT-0500')
Result: Thu Jul 27 2017 19:10:42 GMT+0100 (BST)
new Date('Thu Jul 27 2017 13:10:42 GMT+0500')
Result: Thu Jul 27 2017 09:10:42 GMT+0100 (BST)
I would read the first date current time as being 13:10 which is -0500 hours off from GMT but the result it gives is +5 hours in the future +1 hour BST. In a similar vein the second date works the opposite way being +0500 hours off but returning -5 hours in the past +1 BST.
Firefox works in a similar way but it seems without the BST:
new Date('Thu Jul 27 2017 13:10:42 GMT-0500');
Date 2017-07-27T18:10:42.000Z
new Date('Thu Jul 27 2017 13:10:42 GMT+0500')
Date 2017-07-27T08:10:42.000Z
IE Edge gives me these results:
new Date('Thu Jul 27 2017 13:10:42 GMT-0500')
Thu Jul 27 2017 19:10:42 GMT+0100 (GMT Summer Time)
new Date('Thu Jul 27 2017 13:10:42 GMT+0500')
Thu Jul 27 2017 09:10:42 GMT+0100 (GMT Summer Time)
Can anyone help throw some light on this please?
EDIT - this is not a duplicate of 'Why does Date.parse give incorrect results?' because I am not using the parse() method explicitly.
Please note: I am trying to create a date object that is not in the same timezone as my browser.
If this is not possible I might have to solve my current problem with some basic math (current time +/- the timezone required) - shame if I cannot do this with a native JS Date object.
The default conversion of a Date instance to a string gives you the date and time in terms of the local timezone. If you're doing it in the browser console, you can't even rely on that, because the console itself is free to do whatever it wants. Firefox's console seems to extract the UTC representation; if you call
new Date('Thu Jul 27 2017 13:10:42 GMT-0500').toString()
instead you get the local time.
Dates are based on the idea of UTC timestamps and the notion that local time is generally important. Creating a date from a string gives you a timestamp meaningful (well, as meaningful as possible) for the string, but subsequently the Date instance is by default treated as something relevant to the local context. You can always use the UTC APIs to extract the UTC time if you want.
This question seems to stem from unfamiliarity either with how date strings are parsed by the built–in parser or with how they are formatted by various built–in toString methods.
The same parser is used by Date.parse and the Date constructor, it doesn't matter which is used in terms of how the string is parsed to a time value. The only difference between the two is that Date.parse returns the time value as a number, whereas the Date constructor uses the time value to create a Date instance (which is the only value that a Date instance holds).
The time value itself is milliseconds since 1970-01-01T00:00:00Z, so has no time zone (and means Date instances are effectively UTC). The value returned by getTimezoneOffset and the timezone displayed in toString methods (if there is one) is from the host system, it's not a property of Date instances or the Date constructor.
The timestamp pairs in your question represent exactly the same moment in time, but in different time zones.
Thu Jul 27 2017 13:10:42 GMT-0500 is Thu Jul 27 2017 18:10:42 GMT.
Thu Jul 27 2017 19:10:42 GMT+0100 (BST) is also Thu Jul 27 2017 18:10:42 GMT.
The value returned by Date.prototype.toString is entirely implementation dependent. When you send a date to output, the host may use any method it likes to represent the Date and may format it any way it wants. In the above, it seems the host timezone (UTC+0100) has been used with the default toString, which may return a differently formatted string in different implementations.
However, recent browsers seem to have settled on RFC 2822 format. Other methods that typically return different formats are toISOString and toLocaleString (noting that all three methods could return an ISO 8601 format string and be consistent with the ECMA-262, though I don't know of any implementations that do).
The next two dates also represent exactly the same moment in time:
Thu Jul 27 2017 13:10:42 GMT+0500 is Thu Jul 27 2017 08:10:42 GMT
Thu Jul 27 2017 09:10:42 GMT+0100 (BST) is also Thu Jul 27 2017 08:10:42 GMT
Again, the host timezone has been used to generate the output string.
As for "Firefox works in a similar way but it seems without the BST", see above. ECMA-262 only requires the the format be convenient and human readable. In this case, the browser developers have chosen to use an ISO 8601 format with no offset (i.e. UTC+0000).
So:
Thu Jul 27 2017 13:10:42 GMT-0500 is Thu Jul 27 2017 18:10:42 GMT+0000
2017-07-27T18:10:42.000Z is also Thu Jul 27 2017 18:10:42 GMT+0000
The choice not to use a timezone offset is entirely up to the browser developers and is consistent with ECMA-262.
If your issue is with how date strings are parsed, the duplicate is Why does Date.parse give incorrect results?. If it's with how dates are formatted, the duplicate is Where can I find documentation on formatting a date in JavaScript? The answers to those two questions should answer any issue raised in the OP.
I want to use a javascript library(like Date.js) to parse natural language expressions such as "next tuesday" or "tommorow" but it seems that it evaluates the expression based on current date for example:
Given today's date is: Mon Mar 09 2015 00:00:00 GMT+0100 (CET)
Input: Date.parse('next tuesday');
Output: Tue Mar 10 2015 00:00:00 GMT+0100 (CET)
I would like to parse the expression "next tuesday" given a specific date. Is there a way how one can achieve this using date.js or any other Javascript Library(I tried sugarjs too)? Am I missing something here?
Set today to the date you want to have and make your parse.
https://code.google.com/p/datejs/wiki/APIDocumentation#set
Probably read the API before asking this question.
I have following Java Script (Json) date format
data.d1: "2015-03-26T16:00:00.0000000"
I execute the following
data.d1 = new Date(data.d1);
It gives the following outcome which is wrong to me.
Thu Mar 26 2015 20:00:00 GMT+0400 (Arabian Standard Time)
It should return
Thu Mar 26 2015 16:00:00 GMT+0400 (Arabian Standard Time)
Why there is 4 hour difference?
How i can get the same time (without 4 hours addition to me default time)?
Any hint please
p.s. i can get exact time back by using following line of code
data.d1.setHours(data.d1.getHours() - 4);
Is this the only way?
The 'T' in 2015-03-26T16:00:00.0000000 makes the Date constructor take UTC timezone into consideration. For you it's +4 hours, for me, for instance, it's +2 hours.
If you want the neutral time, you need to remove the 'T' from the string and you'll get the desired result: 2015-03-26 16:00:00.0000000
Fiddle
See this question if you want a pure JS solution without altering your string, it will work I've tested it.
I think I need clarification on something:
I have a string representing a date in a format like this:
'2013-12-24 12:30:00'
and if I pass it to Date(), then I get the following output
new Date('2013-12-24 12:30:00')
// --> Tue Dec 24 2013 12:30:00 GMT+0100
because iOS has problems with this, I read that I should use T as separator, however
new Date('2013-12-24T12:30:00')
// --> Tue Dec 24 2013 13:30:00 GMT+0100
the result adds one hour. I guess it has something to do with summer or winter, but what exactly does the T stand for, and why is the result different? I meanwhile solved my problem by passing separate parameters to the Date but I would still like to know where this extra hour is coming from.
new Date('2013-12-24T12:30:00')
treats the time as UTC, so it's 12:30 in Greenwich and 13:30 in your timezone.
new Date('2013-12-24 12:30:00')
is a Chrome extension (or bug) that doesn't work in other browsers. It treats the time as local, so it's 12:30 in your timezone (GMT+1) and 11:30 in Greenwich.
If you look closely... you will notice adding a T makes the time in 24-hour format.
new Date('2013-12-24T12:30:00')
// --> Tue Dec 24 2013 13:30:00 GMT+0100
Compared to
new Date('2013-12-24 12:30:00')
// --> Tue Dec 24 2013 12:30:00 GMT+0100
I guess its stands for Long time pattern. Refer this for more.