Date.toLocaleString() returns this in Chrome:
Mon Jan 18 2010 16:47:42 GMT+1100 (AUS Eastern Daylight Time)
In firefox, it's this:
Monday, 18 January 2010 4:47:42 PM
Browser version doesn't seem to matter. Anyone have a suggestion on this one?
Date.toLoacaleString is an issue on chrome:
http://code.google.com/p/chromium/issues/detail?id=29779&q=tolocalestring&colspec=ID%20Stars%20Pri%20Area%20Type%20Status%20Summary%20Modified%20Owner%20Mstone%20OS
As CMS answered above, these methods can return pretty much anything they want, hopefully in a representation that is readable to someone in that locale (language + cultural conventions) To obtain a particular formatting of a Date, you need to use a library like DateJS or Dojo.
Related
In the Australia/Sydney time zone, Firefox seems to give an incorrect time for toLocaleString on dates:
new Date("2019-04-04T01:12:38.553309+00:00").toLocaleString() gives "4/4/2019, 11:12:38 AM".
new Date("2019-04-04T01:12:38.553309+00:00").toString() gives correct result "Thu Apr 04 2019 12:12:38 GMT+1100 (AEDT)".
I've been able to reproduce this on my phone as well as my computer. I asked a colleague to test, and Firefox gave the correct output on his computer.
Chromium gives the correct time for toLocaleString.
Is this a bug in Firefox? Do I have some misconfiguration?
I assume the correct approach here is to use a 3rd party library like date-fns to format my Dates instead.
Update: for now I have switched to using dateFns.format(timestamp, 'yyyy/MM/dd HH:mm:ss'). We don't have any US customers anyway.
If I pass the unix milliseconds timestamp value for 1/1/1753 (at midnight) (-6847786800000) to the JavaScript Date() constructor in Chrome, the Date Chrome gives me looks really weird. I get other weirdness when I use the Date() constructor that takes seven parameters. Examples are below.
Chrome: new Date(-6847786800000): Mon Jan 01 1753 00:03:58 GMT-0456 (Eastern Standard Time)
Firefox: new Date(-6847786800000): Mon Jan 01 1753 00:00:00 GMT-0500 (Eastern Standard Time)
Note how Chrome made the time 3:58 and the timezone GMT-0456 (the weird timezone appears to be about the same amount as the weird time (4 minutes).)
Chrome: new Date(1753, 0, 1, 0, 0, 0, 0): Mon Jan 01 1753 00:00:00 GMT-0456 (Eastern Standard Time)
Firefox: new Date(1753, 0, 1, 0, 0, 0, 0): Mon Jan 01 1753 00:00:00 GMT-0500 (Eastern Standard Time)
Note how Chrome gives me 0:00 for the time, but still has that GMT-0456 timezone.
Playing around with various dates, this odd behavior seems to start with dates before 1884 - not sure of the exact date. 1/1/1884 acts as you would expect, but 1/1/1883 gets this "off by 3:58" behavior.
Is this a bug or am I missing something?
I tested this on:
Chrome 67.0.3396.99 (Official Build) (64-bit);
Firefox 61.0 (64-bit);
IE 11 and Edge 42.17134.1.0 give the same results as Firefox
UPDATE
This does not look like a duplicate of Browsers, time zones, Chrome 67 Error to me. That question is talking about timezones being different. It uses 1900 as an example. I'm talking about the time being different. And it only affects stuff before 1884. It does not affect 1900 dates.
Why would changing the timezone change the actual time? I'm not a timezone wizard but that still seems wrong to me.
UPDATE
So yeah, probably a duplicate in some sense. Don't know for sure if Chrome changed it's behavior with this. But it does come down to the fact that right now Chrome will see old unix timestamps, before 11/18/1883 at 12:03:58 PM, as different points in time than other browsers. So watch out if you need to work with timestamps for old dates. I switched away from using timestamps to avoid this issue.
On the console in chrome browser of windows and Ubuntu I entered Date() object and I found both have a different way to write the timezone for that date.
Ubuntu:
"Thu Aug 10 2017 18:45:18 GMT+0530 (IST)"
Windows:
"Thu Aug 10 2017 18:45:18 GMT+0530 (India Standard Time)"
According to my use case the output on Ubuntu is correct, the time zone IST is what expected. But on windows it always shows up India Standard Time.
Is there a way to fix this for windows.
According to my use case the output on Ubuntu is correct
Neither of them is correct. Or incorrect. The string form of a Date from toString (which is what those appear to be) is almost completely unspecified. The only requirement is that it represent the date, and that Date() and Date.parse should be able to parse it.
If you want something reliable cross browser*, use toISOString.
* Obsolete browsers may not have toISOString. Even only vaguely-modern browsers do.
I am new to DateJs, and the http://www.datejs.com/ is 530 so I can't find documentation for each method.
I need to get the last day of specific year-month. For example :
I need the last fay of July,2015, which should be 31th,July 2015. I tried below script:
<script src="<%=application.getContextPath()%>/js/lib/datejs/date-zh-CN.js"></script>
to=Date.today().set({year:2015,month:6}).final();//which returns Fri Jul 03 2015 00:00:00 GMT+0800 (中国标准时间)
or
to=Date.today().set({year:2015,month:6}).final().day();//which returns Sat Jul 04 2015 00:00:00 GMT+0800 (中国标准时间)
Which are wrong (The day I am ruining the script is at Aug 3rd, 2015). I guess I am using the method final() wrongly, but I can't get a direct example from https://github.com/datejs/Datejs .
Within DateJS there is an moveToLastDayOfMonth function.
Example
Date.july().moveToLastDayOfMonth()
or,
Date.today().set({year:2015,month:6}).moveToLastDayOfMonth()
Hope this helps.
I have never used DateJS, but from a quick study, I guess this is what you'd want:
Date.today().set({year:2015,month:7,day:1}).add(-1).days()
HTH
There's a specific method to do that. First you have to set the date, obviously, and that can be done on an initialized Date object with now() or today(). I'd suggest today as that will zero out the time values:
Date.today().set({year:2015,month:6}).moveToLastDayOfMonth()
This will get you to the exact data you need.
Secondly, if you're using DateJS PLEASE GOD use the latest updated fork (disclaimer, I maintain it, I need to give it a little love but it fixes so many issues with the original library).
You can find that here: https://github.com/abritinthebay/datejs
It's also available as the npm datejs package and in bower. A simple npm install datejs will do if you use NodeJS.
I am using date.js in my project, and I am encountering something I didn't expect with respect to dates that had time components of exactly noon or exactly midnight.
When I use the native javascript Date.parse method, I get the result I expected when parsing a date:
// plain old javascript
var date = new Date(Date.parse("10/21/2010 12:00:00 PM"));
alert(date);
I get this:
Thu Oct 21 2010 12:00:00 GMT-0500 (Central Daylight Time)
I interpret this as noon on October 21, 2010, which is what I think my input date is. However, when I import date.js and try something similar,
// using date.js
var date = Date.parseExact("10/21/2010 12:00:00 PM", "M/d/yyyy hh:mm:ss tt");
alert(date);
I get this:
Fri Oct 22 2010 00:00:00 GMT-0500 (Central Daylight Time)
This looks to me like midnight on the following day. I have no idea why it's interpreting this as midnight, or at any rate why it's interpreting this differently than the default Date.parse in javascript. Am I confused over the meaning of 12:00 PM? Am I misusing date.js's parseExact?
Looks like a version issue:
http://jsfiddle.net/4QK8Q/
http://jsfiddle.net/JKg3n/
The first one is your file (from the google code base), the second is from their website (datejs.com). Funnily enough they look like the same version, but obviously aren't. I'm not familiar enough with the library to tell what's going on, but I suggest filing a bug report.
This is a fairly old question, but for those who may stumble upon this in a search, it's highly suggested that you switch to the currently maintained version of Date.js (https://github.com/abritinthebay/datejs/) if you're encountering unexpected behavior.
The versions on the Google code base and datejs.com both have unfixed bugs that are unlikely to ever be addressed, as the original developer seems to have abandoned the project.