I am trying to convert a datetime (raw format in UTC: 2012-12-05T21:55:00) to readable local time format but the output varies across browsers:
DateTime = new Date(DateTime);
alert(DateTime);
In Chrome it appears as:
Wed Feb 20 2013
05:31:00 GMT +0800
(Malay Peninsula
Standard Time)
and in IE:
Wed Feb 20 05:31:00
UTC+0800 2013
Hence, I applied a .format to it:
DateTime = new Date(DateTime);
DateTime.format('dd MMM, yyyy hh:mm tt')
alert(DateTime);
This format appears good and consistent across Chrome and IE9:
20 Feb, 2013 05:31 AM
but there's an issue in displaying it in IE8 and Safari, it shows the date as:
NaN, 000NaN
NaN:NaN AM
I tried other JS plugins like date ninja but no help either. Can anyone advise how to go about the NaN issue? Thanks.
I faced 'exactly' the same issue you are facing a few months back. Use moment.js. It gives consistent date formats in Chrome, FF and IE(Including IE 8)
Related
I have a Ajax request to fetch Django data in Json. I receive the response and everything is ok, I keep dateTime in my Django app as naive date since I don't have to manage timezone. I want date/time to be showed like they are saved.
Ok in my javascript, when I do a:
console.log(item.fields.timeStamp);
I receive:
2020-03-29T21:00:00.143
On both desktop and my iPhone, and that is wath I expect, but when I do that:
alert(new Date(item.fields.timeStamp));
I receive:
Sun Mar 29 2020 20:05:21 GMT-0400 (heure d’été de l’Est)
On my desktop and:
Sun Mar 29 2020 16:05:21 GMS-0400 (EDT)
And that is totally wrong!!
So all timeStamp in my app are totally off on mobile devices.
What can be my problem ?
You have a problem with timeZone manage. Its ideal that you save all dates in UTC format on database and converts it in each client according to timezone the you want.
You could do it using native javascript
console.log(new Date('2020-03-29T21:00:00.143').toLocaleString('es-ES', {timeZone: 'America/Bogota'}));
console.log(new Date('2020-03-29T21:00:00.143').toLocaleString('es-ES', {timeZone: 'Asia/Shanghai'}));
or with moment and moment-timezone libraries
const format = 'YYYY/MM/DDTHH:mm:ss.ZZZ';
const formatOut = 'YYYY/MM/DD HH:mm:ss';
console.log(moment('2020-03-29T21:00:00.143', format).tz('America/Bogota').format(formatOut));
console.log(moment('2020-03-29T21:00:00.143', format).tz('Asia/Shanghai').format(formatOut));
I have a function that gets the date in the DATETIME format:
2015-06-18 00:00:00
Doing moment.utc("2015-06-18 00:00:00").toDate() will display different results in Firefox and Chrome:
Firefox: Date 2015-06-18T00:00:00.000Z
Chrome: Thu Jun 18 2015 03:00:00 GMT+0300 (EEST)
Also, using new Date("2015-06-18 00:00:00") will return Invalid Date in Firefox, but adding a "T" before the hours will fix that issue. But then if I do new Date("2015-06-18T00:00:00") will return:
Firefox: Date 2015-06-17T21:00:00.000Z
Chrome: Thu Jun 18 2015 03:00:00 GMT+0300 (EEST)
It's driving me nuts.
How can I get both browsers to show the same hour?
How can I get Firefox to display the result in Chrome's format?
The whole point of using a dedicated date library is to obtain transparent cross-browser date features. However, as soon as you run .toDate() you get back the native Date object. If you then convert it to string by using the builtin Date.toString() method you've finally dropped all the library goodies and got back to vanilla JavaScript.
Tips:
Don't use strings expect for display purposes
Use the library features to generate those strings
try
new Date("2015-06-18T00:00:00").toString()
looks the same on both for me
I get dates from the database in this format:
yyyy-mm-dd
When I create a javascript Date object using this string, it builds a day before the date.
You can test this in your console:
var d = new Date("2015-02-01");
d
You will get January 31st! I've tested many theories, but none answer the question.
The day is not zero-based, otherwise it would give Feb 00, not Jan 31
It's not performing a math equation, subtracting the day from the month and/or year
Date(2015-02-01) = Wed Dec 31 1969
Date("2015-01") = Wed Dec 31 2014
It is not confusing the day for the month
Date("2015-08-02") = Sat Aug 01 2015
If this were true the date would be Feb 08 2015
If you create a Date using a different format, it works fine
Date("02/01/2015") = Feb 1st, 2015
My conclusion is that js does this purposefully. I have tried researching 'why' but can't find an explanation. Why does js build dates this way, but only with this format? Is there a way around it, or do I have to build the Date, then set it to the next day?
PS: "How to change the format of the date from the db" is not what I'm asking, and that is why I'm not putting any db info here.
Some browsers parse a partial date string as UTC and some as a local time,
so when you read it the localized time may differ from one browser to another
by the time zone offset.
You can force the Date to be UTC and add the local offset if you
want the time to be guaranteed local:
1. set UTC time:
var D= new Date("2015-02-01"+'T00:00:00Z');
2. adjust for local:
D.setMinutes(D.getMinutes()+D.getTimezoneOffset());
value of D: (local Date)
Sun Feb 01 2015 00:00:00 GMT-0500 (Eastern Standard Time)
Offset will be whatever is local time.
Some differences between browsers when time zone is not specified in a parsed string:
(tested on Eastern Standard Time location)
(new Date("2015-02-01T00:00:00")).toUTCString();
Firefox 35: Sun, 01 Feb 2015 05:00:00 GMT
Chrome 40: Sun, 01 Feb 2015 00:00:00 GMT
Opera 27: Sun, 01 Feb 2015 00:00:00 GMT
IE 11: Sun, 01 Feb 2015 05:00:00 GMT
IE and Firefox set the Date as if it was local, Chrome and Opera as if it was UTC.
In javascript, Date objects are internally represented as the number of milliseconds since Jan 1st 1970 00:00:00 UTC. So instead of thinking of it as a "date" in the normal sense, try thinking of a Date object as a "point in time" represented by an integer number (without timezone).
When constructing your Date object using a string, you are actually just calling the parse function. Most date time formats (including ISO 8601) allow you to reduce the precision of a date string.
For reduced precision, any number of values may be dropped from any
of the date and time representations, but in the order from the least
to the most significant.
e.g. 2015-02-01 would represent the day February 1st 2015.
This causes a dilemma for javascript because a Date object is always accurate to the millisecond. Javascript cannot store a reduced accuracy date since it is just an integer of milliseconds since 1st Jan 1970. So it does the next best thing which is to assume a time of midnight (00:00:00) if not specified, and a timezone of UTC if not specified.
All valid javascript implementations should give the same result for this:
var d = new Date("2015-02-01");
alert(d.getTime());
1422748800000
The out-by-1-day issue comes when outputting the date either to some (often unclear) debugger or using the getter methods because the local timezone is used. In a browser, that will be your operating systems timezone. Anyone "west" of Greenwich Mean Time may see this problem because they have a negative UTC offset. Please note there are UTC equivalent functions too which use the UTC timezone, if you are really just interested in representing a date rather than a point in time.
So now, its 9:23am. I have a UTC date string that represents the current date, that looks like this "2012-07-17T09:23:27.75"
I want that in a date object, so I can display a nicely formatted date, so I:
var myDate = new Date("2012-07-17T09:23:27.75")
// Gives --> Tue Jul 17 2012 10:23:27 GMT+0100 (GMT Daylight Time)
So because of daylight saving time I'm getting an hour-out issue. I can see that myDate.getTimezoneOffset() gives me -60, what's the standard / best practice way to get my date to actually reflect the current correct time? Have I just entered javascript date hell?
Try momentjs.com. I really found it handy for such things.
var myDate = moment("2012-07-17T09:23:27.75");
Gives you a date instance in your timezone (that basically configured on your computer). Moreover momentjs has nice human friendly formattings like "a couple of seconds ago", "a month ago",...
Dates are really a hell in JS (but not only in JS). The best thing you can do is to always only transport in UTC between browser <-> server. Then on the server convert it to what time format you like, you obviously only have to be consistent. That way I managed to handle date-times properly.
Try removing the 'T'
I was debugging some date time format issue in chrome when I found out that in console
new Date('2016-04-16T15:15:00') returns Sat Apr 16 2016 16:15:00 GMT+0100 (GMT Daylight Time)
while
new Date('2016-04-16 15:15:00') returns Sat Apr 16 2016 15:15:00 GMT+0100 (GMT Daylight Time)
I use the 3 browsers to output this result.
Chrome:
new Date().toLocaleString()
> "Sun Sep 04 2011 21:40:04 GMT+0800 (HKT)"
Safari:
new Date().toLocaleString()
> "2011年9月4日 下午09时54分51秒格林尼治标准时间+0800"
FF:
new Date().toLocaleString()
> "Sun Sep 4 21:46:03 2011"
why not the same output result? timezoom?
It depends on the configuration of the computer, the user's preferred date format, obviously the user's locale, and how the browser determines this.
You should really prefer using a proper date library such as datejs for formatting.
See their Date.toString() and format specifiers.
That's a bug in webkit, actually; in particular in Chrome but Safari is indeed affected too: http://code.google.com/p/chromium/issues/detail?id=3607
toLocaleString() does not translate to the locale!
The worst is, it's closed as WontFix. How is that possible? We should try and re-open it. The conclusion on the bug is that somewhen a new javascript globalization apis (that is well explained here) will appear. That doesn't sound like a solution to me!
In any case, if possible, follow #arnaud576875 suggestion to use datejs which is old but still very good.
Check this link
And this example:
var event = new Date(Date.UTC(2012, 11, 20, 3, 0, 0));
// British English uses day-month-year order and 24-hour time without AM/PM
console.log(event.toLocaleString('en-GB', { timeZone: 'UTC' }));
// expected output: 20/12/2012, 03:00:00
// Korean uses year-month-day order and 12-hour time with AM/PM
console.log(event.toLocaleString('ko-KR', { timeZone: 'UTC' }));
// expected output: 2012. 12. 20. 오전 3:00:00