I want to convert a string into a date "as it is".
const date = "8/16/2019"
console.log(new Date(date))
However, I get:
As you can see I get the prevous day. I was thinking that it might be a timezone issue, even though there is no timezone that I am converting it from.
Any suggestions how to convert is as it is?
I appreciate you replies!
If your format is consistent, you could split on / and use Date.UTC. Creating your new Date from that would ensure it's UTC.
const date = "8/16/2019"
const [month,day,year] = date.split("/");
const utcDate = Date.UTC(year,month-1,day);
console.log(new Date(utcDate));
const date = "8/16/2019"
console.log(new Date(date).toLocaleString("en-US", {timeZone: "Asia/kolkata"}))
Note:- You need to add timezone
You can use toLocaleDateString
console.log(new Date("8/16/2019").toLocaleDateString('en-us', {timeZone: "Asia/Kolkata"}))
new Date("8/16/2019") will create a date object using your current timezone. Add a "Z" at the end if you want your date to be in UTC.
console.log(new Date("8/16/2019Z"))
EDIT
It appears that Firefox is not implementing the parsing of standard date format. Unfortunately until recently how exactly was a date parsed was completeley based on heuristics and intrinsically non portable.
Looking at Firefox bug tracker seems the issue has been discussed but the problem is still present (some toolkit just works around by replacing "Z" with "+00:00" before calling the parser).
The only way to be sure on every browser is to parse the string yourself and build the date from the fields. I didn't notice because I'm using chrome instead (in both chrome and Node works as expected).
EDIT 2
After more investigation seems the standard requires that:
If you use yyyy-mm-ddThh:mm:ssz then you get what ISO format for datetime defines it to be. Also the syntax described in the standard is not very precise and for example is not clear to me if the time zone can be present when no time is present (Chrome says yes, Firefox says no).
If you use another format then anything goes (so for example there is no string that is guaranteed to issue an invalid date response).
In other words new Date("8/16/2019") is not portable Javascript (with the meaning that you don't know what date / time / timezone you will get, if any). Either you parse yourself the date or you just live with what that version of that Javascript engine in that moment decides to give you.
Related
The API I am using, returns dates in a format like YYYY-MM-DDTHH:MM:SS+0200. When I try to create a Date object of that, it usually works:
new Date('2021-06-28T12:00:00+0200');
However, some users with an older version of Safari/iOS complain, that they get some "Invalid Date", which I cannot recreate because all my devices are up to date.
How can I fix the date parsing so that it works across all browsers? Is the date string incorrect? Is the parsing incorrect?
How can I test if it actually does? Because as I said, it already seems to be working on alle the devices I have access to, but unfortunately it doesn’t on some devices I don’t have access to...
Thank you very much!
I'd suggest using a library such as luxon for parsing dates. It should handle both +hhmm and +hh:mm UTC offsets.
You can parse to a luxon DateTime, then simply call .toJSDate() to get a Date, this should mean minimal code changes:
let { DateTime } = luxon;
console.log("Using +hhmm UTC offset:");
let input = '2021-06-28T12:00:00+0200';
let d = (DateTime.fromISO(input));
console.log('Input:', input)
console.log('toJSDate:', d.toJSDate())
console.log('ISO time (Local):', d.toISO())
console.log("\nUsing +hh:mm UTC offset:");
input = '2021-06-28T12:00:00+02:00';
d = (DateTime.fromISO(input));
console.log('Input:', input)
console.log('toJSDate:', d.toJSDate())
console.log('ISO time (Local):', d.toISO())
<script src="https://moment.github.io/luxon/global/luxon.js"></script>
I am having a bit of a nightmare working with a CMS that saves datetimes without timezones. For a wide variety of infrastructure reasons I am unable to adjust core files, I can only adjust some of the javascript of the CMS field itself, and not include external libraries (or the dayjs UTC plugin).
How it currently works:
CMS Saves datetime string like so: 2020-10-29 05:00 which is missing the timezone
When reloading, the dayjs parses the string 2020-10-29 05:00 as UTC and changes the time based on the browser locale.
If you are using a browser that it not UTC, the time displayed will not correspond to the saved string
My hacky idea:
When loading the string, get the browser's timezone
Modify the string 2020-10-29 05:00 to include the browser's timezone, or offset the date object so that when it is parsed as 'local', it will display correctly
My initial thought was just to add/subtract the offset before displaying but it still didn't seem to work (I think due to getTimezoneOffset not adjusting for daylight savings?):
let date = new Date('2020-10-29 05:00')
console.log(new Date(date.setMinutes(date.getMinutes() + new Date().getTimezoneOffset())))
I suppose an alternate form of this question is: Is there a way to parse a UTC datetime string as though it were local?
If the string is UTC, you should parse it as UTC and then do everything in UTC. I think the easiest way is to parse the string as UTC with your own function or library.
Also, given:
new Date('2020-10-29 05:00')
some browsers will return an invalid date (they treat it as a malformed version of the supported format YYYY-MM-DDTHH:mm:ss).
Generally, using the built–in parser is strongly discouraged because of browser inconsistencies. Also, messing with timezone offsets can also lead to difficult to find issues (like when applying the offset causes the date to cross a DST boundary).
A simple function to do the job:
function parseAsUTC(s) {
let [y, m, d, H, M] = s.split(/\D/);
return new Date(Date.UTC(y, m-1, d, H, M));
}
let s = '2020-10-29 05:00';
console.log(parseAsUTC(s));
I'm looking at a semi-old codebase where the following code is used to format a date in YYYY-MM-DD format according to a user's locale:
new Date('2000-01-01').toLocaleDateString(navigator.language)
However, this doesn't work in Firefox because new Date('2000-01-01') returns a datetime (time is 00:00) in UTC while toLocaleDateString uses the user's local timezone, so the above will return "December 31, 1999" for a user in the US.
What is the sane, safe way of doing this across browsers? Is it possible to do without one or more extra dependency?
If you add a timestamp to that date string it seems to be initialized with that time in the local timezone:
new Date('2000-01-01T00:00:00');
I tried this in both Chrome and Firefox and it seems to work as you want. However, creating a date with a string should be avoided as there's no guarantee it works consistently across different browsers. It's better to break the date into its parts, parse it as numeric values and initialize the date that way:
var dateParts = '2000-01-01'.split('-').map(Number);
new Date(
dateParts[0],
dateParts[1] - 1, // month is base 0
dateParts[2]
);
Update: Turns out Safari assumes UTC even if appending a timestamp to the date string, so this is one more reason to parse it and initialize the date with numeric values, as this always uses the local timezone.
A leading zero for the day within a string seems to break the Javascript Date object in Chrome. There are also some inconsistencies between browsers, since Firefox handles the leading zero correctly, but fails when the zero is not included. See this example: https://jsfiddle.net/3m6ovh1f/3/
Date('2015-11-01'); // works in Firefox, not in Chrome
Date('2015-11-1'); // works in Chrome, not in Firefox
Why? Is there a good way to work around/with the leading zero?
Please note, the strings are coming from MySQL via AJAX and all dates will contain the leading zero, and I can fix this by formating the dates server-side. What format would work the best?
EDIT
Just to specify what my problem was, it looks like Chrome is applying a time zone to the YYYY-MM-DD format, which reverts the Nov. 1st date back to the Oct. 31st date (because of my EDT local time).
According to ECMA-262 (5.1):
The function first attempts to parse the format of the String according to the rules called out in Date Time String Format (15.9.1.15). If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats.
The date/time string format as described in 15.9.1.15 is YYYY-MM-DDTHH:mm:ss.sssZ. It can also be a shorter representation of this format, like YYYY-MM-DD.
2015-11-1 is not a valid date/time string for Javascript (note it's YYYY-MM-D and not YYYY-MM-DD). Thus, the implementation (browser) is able to do whatever it wants with that string. It can attempt to parse the string in a different format, or it can simply say that the string is an invalid date. Chrome chooses the former (see DateParser::Parse) and attempts to parse it as a "legacy" date. Firefox seems to choose the latter, and refuses to parse it.
Now, your claim that new Date('2015-11-01') doesn't work in Chrome is incorrect. As the string conforms to the date/time string format, Chrome must parse it to be specification compliant. In fact, I just tried it myself -- it works in Chrome.
So, what are your options here?
Use the correct date/time format (i.e. YYYY-MM-DD or some extension of it).
Use the new Date (year, month, date) constructor, i.e. new Date(2015, 10, 1) (months go from 0-11) in this case.
Whichever option is up to you, but there is a date/time string format that all specification compliant browsers should agree on.
As an alternative, why not use unix timestamps instead? In JavaScript, you would would multiply the timestamp value by 1000,
e.g
var _t = { time: 1446220558 };
var _d = new Date( _t.time*1000 );
Test in your browser console:
new Date( 14462205581000 );
// prints Fri Oct 30 2015 11:55:58 GMT-0400 (EDT)
There's a little benefit in it as well (if data comes via JS) - you'd save 2 bytes on every date element '2015-10-30' VS 1446220558 :)
Using Moment.js I can't transform a correct moment object to a date object with timezones. I can't get the correct date.
Example:
var oldDate = new Date(),
momentObj = moment(oldDate).tz("MST7MDT"),
newDate = momentObj.toDate();
console.log("start date " + oldDate)
console.log("Format from moment with offset " + momentObj.format())
console.log("Format from moment without offset " + momentObj.utc().format())
console.log("(Date object) Time with offset " + newDate)
console.log("(Date object) Time without offset "+ moment.utc(newDate).toDate())
Use this to transform a moment object into a date object:
From http://momentjs.com/docs/#/displaying/as-javascript-date/
moment().toDate();
Yields:
Tue Nov 04 2014 14:04:01 GMT-0600 (CST)
As long as you have initialized moment-timezone with the data for the zones you want, your code works as expected.
You are correctly converting the moment to the time zone, which is reflected in the second line of output from momentObj.format().
Switching to UTC doesn't just drop the offset, it changes back to the UTC time zone. If you're going to do that, you don't need the original .tz() call at all. You could just do moment.utc().
Perhaps you are just trying to change the output format string? If so, just specify the parameters you want to the format method:
momentObj.format("YYYY-MM-DD HH:mm:ss")
Regarding the last to lines of your code - when you go back to a Date object using toDate(), you are giving up the behavior of moment.js and going back to JavaScript's behavior. A JavaScript Date object will always be printed in the local time zone of the computer it's running on. There's nothing moment.js can do about that.
A couple of other little things:
While the moment constructor can take a Date, it is usually best to not use one. For "now", don't use moment(new Date()). Instead, just use moment(). Both will work but it's unnecessarily redundant. If you are parsing from a string, pass that string directly into moment. Don't try to parse it to a Date first. You will find moment's parser to be much more reliable.
Time Zones like MST7MDT are there for backwards compatibility reasons. They stem from POSIX style time zones, and only a few of them are in the TZDB data. Unless absolutely necessary, you should use a key such as America/Denver.
.toDate did not really work for me, So, Here is what i did :
futureStartAtDate = new Date(moment().locale("en").add(1, 'd').format("MMM DD, YYYY HH:MM"))
hope this helps
Since momentjs has no control over javascript date object I found a work around to this.
const currentTime = new Date();
const convertTime = moment(currentTime).tz(timezone).format("YYYY-MM-DD HH:mm:ss");
const convertTimeObject = new Date(convertTime);
This will give you a javascript date object with the converted time
The question is a little obscure. I ll do my best to explain this. First you should understand how to use moment-timezone. According to this answer here TypeError: moment().tz is not a function, you have to import moment from moment-timezone instead of the default moment (ofcourse you will have to npm install moment-timezone first!). For the sake of clarity,
const moment=require('moment-timezone')//import from moment-timezone
Now in order to use the timezone feature, use moment.tz("date_string/moment()","time_zone") (visit https://momentjs.com/timezone/ for more details). This function will return a moment object with a particular time zone. For the sake of clarity,
var newYork= moment.tz("2014-06-01 12:00", "America/New_York");/*this code will consider NewYork as the timezone.*/
Now when you try to convert newYork (the moment object) with moment's toDate() (ISO 8601 format conversion) you will get the time of Greenwich,UK. For more details, go through this article https://www.nhc.noaa.gov/aboututc.shtml, about UTC. However if you just want your local time in this format (New York time, according to this example), just add the method .utc(true) ,with the arg true, to your moment object. For the sake of clarity,
newYork.toDate()//will give you the Greenwich ,UK, time.
newYork.utc(true).toDate()//will give you the local time. according to the moment.tz method arg we specified above, it is 12:00.you can ofcourse change this by using moment()
In short, moment.tz considers the time zone you specify and compares your local time with the time in Greenwich to give you a result. I hope this was useful.
To convert any date, for example utc:
moment( moment().utc().format( "YYYY-MM-DD HH:mm:ss" )).toDate()
let dateVar = moment('any date value');
let newDateVar = dateVar.utc().format();
nice and clean!!!!
I needed to have timezone information in my date string. I was originally using moment.tz(dateStr, 'America/New_York').toString(); but then I started getting errors about feeding that string back into moment.
I tried the moment.tz(dateStr, 'America/New_York').toDate(); but then I lost timezone information which I needed.
The only solution that returned a usable date string with timezone that could be fed back into moment was moment.tz(dateStr, 'America/New_York').format();
try (without format step)
new Date(moment())
var d = moment.tz("2019-04-15 12:00", "America/New_York");
console.log( new Date(d) );
console.log( new Date(moment()) );
<script src="https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.24.0/moment.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/moment-timezone/0.5.23/moment-timezone-with-data.min.js"></script>
moment has updated the js lib as of 06/2018.
var newYork = moment.tz("2014-06-01 12:00", "America/New_York");
var losAngeles = newYork.clone().tz("America/Los_Angeles");
var london = newYork.clone().tz("Europe/London");
newYork.format(); // 2014-06-01T12:00:00-04:00
losAngeles.format(); // 2014-06-01T09:00:00-07:00
london.format(); // 2014-06-01T17:00:00+01:00
if you have freedom to use Angular5+, then better use datePipe feature there than the timezone function here. I have to use moment.js because my project limits to Angular2 only.
new Date(moment()) - could give error while exporting the data column in excel
use
moment.toDate() - doesn't give error or make exported file corrupt