I have built an application that is using pure javascript Date objects and date-fns for formatting and manipulating the objects.
The application functions perfectly in GMT where I developed it however I'm now on the West Coast of The States and I've discovered that many of my date objects are thrown out because of the timezone difference.
I am creating date objects from strings, either just YYYY-MM-DD or YYYY-MM-DD HH:mm, for example new Date('2018-01-19') or new Date('2018-01-19 08:00').
The issue is that when I create a date from a string of the format YYYY-MM-DD it creates the object disregarding the local timezone.
const date1 = new Date('2018-01-19');
const date2 = new Date('2018-01-19 00:00');
const dateString1 = format(date1, 'YYYY-MM-DD'); // gives '2018-01-18'
const dateString2 = format(date2, 'YYYY-MM-DD'); // gives '2018-01-19'
The behaviour is not consistent depending on whether you pass a time or not. If you pass a time then the date object is fixed to the local timezone, but if you don't then it is fixed to UTC. What I would like is that if I pass a datestring without the time (just year, month and day) that it would also create a date object assuming that it would be the start of the day in the local timezone.
Why is this? And do I just have to set the time as 00:00 each time I create a Date object?
"Why is this?"
From the documentation: "Support for ISO 8601 formats differs in that date-only strings (e.g. "1970-01-01") are treated as UTC, not local."
Parsing dates from strings isn't really advised; the recommendation is to do it manually by splitting the string and using the individual components as parameters. Or use a date library.
Related
I tried with two methods to generate Date first by passing whole date string and second with year, month, day combination. But I am getting different outputs while the same date is being provided. The Day is not right. It should be 30 June in the first too.
const oldDate = new Date('2020-06-30');
const newDate = new Date('2020', '05', '30');
console.log(oldDate.toString(), newDate.toString());
When you instantiate a Date by passing a string, it's supposed to be a full ISO 8601 string which specifies the time zone. As you dont specify it, it takes GMT+0, and you seem to be located at GMT-7. You should write this instead:
console.log(new Date('2020-06-30T00:00:00-07:00').toString());
The Date constructor that accepts multiple arguments expects them to be numbers, and accepts the month number as a 0-based value (0 = January). The values are expected to be in local time.
The Date constructor accepting a single string argument parses the string according to the specified rules (which apply to your example) and, possibly, unspecified fallback rules the JavaScript engine implementer chose to add (in your case, though, the fallback isn't necessary). When there's no timezone indicator on the string, Date-only forms such as yours are parsed in UTC (date/time forms are parsed in local time).
(The Date constructor accepting a single number expects that number to be milliseconds-since-The-Epoch [Jan 1st, 1970 at midnight, UTC].)
Below format is considered as GMT time and it tries to convert to your local timezone. That's why you notice 7 hours subtracted.
new Date('2020-06-30')
whereas,
Below format is considered as local timezone and no further conversion happen.
new Date('2020', '05', '30');
According to MDN docs:
dateString
A string value representing a date, specified in a format recognized by the Date.parse() method. (These formats are IETF-compliant RFC 2822 timestamps, and also strings in a version of ISO8601.)
Note: Parsing of date strings with the Date constructor (and Date.parse(), which works the same way) is strongly discouraged due to browser differences and inconsistencies.
Support for RFC 2822 format strings is by convention only.
Support for ISO 8601 formats differs in that date-only strings (e.g. "1970-01-01") are treated as UTC, not local.
Therefore, when you create date via new Date("2020-06-30") it creates date object in 0 timezone and adjusts time to show it equal to your time zone.
I wish to create a new Date in JS, but have it be cast as UTC time. For example, suppose castAsUTC() produces the following desired effect:
var x = new Date('2019-01-01T00:00:00') // In local time (PST)
castAsUTC(x).toISOString(); // => '2019-01-01T00:00:00Z'
// x.toISOString() gives us '2019-01-01T08:00:00Z', which is undesired
Currently, my function looks like this:
function castAsUTC(date) {
return new Date(x.toLocaleString() + '+00:00');
}
Is there a cleaner/nicer way of producing the same effect? Thanks in advance!
EDIT: To be more specific, I'm interested in transforming the date's timezone, without changing its actual value with as little arithmetic as possible. So calling .toISOString() will produce the same date as it is in local time.
I am currently using the moment-timezone library, but I can't seem to get the desired effect using that, either. I would definitely accept an answer that uses Moment.js
You can switch a Moment instance to UTC using the utc function. Then just use format to get whatever the specific output you want from it.
If indeed the string you have is like the one shown, then the easiest thing to do would be to append a Z to indicate UTC.
var input = '2019-01-01T00:00:00';
var date = new Date(input + 'Z');
var output = date.toISOString();
Or, if you would like to use Moment.js, then do this:
var input = '2019-01-01T00:00:00';
var m = moment.utc(input);
var output = m.format();
You do not need moment-timezone for this.
tl;dr;
You formatted the date wrong. Add the letter "Z" to the end of your date string and it will be treated as UTC.
var x = new Date('2019-01-01T00:00:00Z') // Jan 1, 2019 12 AM UTC
These formatting issues are easier to manage with a library like momentjs (utc and format functions) as described in other answers. If you want to use vanilla javascript, you'll need to subtract out the timezone offset before calling toISOString (see warnings in the longer answer below).
Details
Date in javascript deals with timezones in a somewhat counter intuitive way. Internally, the date is stored as the number of milliseconds since the Unix epoch (Jan 1, 1970). That's the number you get when you call getTime() and it's the number that's used for math and comparisons.
However - when you use the standard string formatting functions (toString, toTimeString, toDateString, etc) javascript automatically applies the timezone offset for the local computers timezone before formatting. In a browser, that means it will apply the offset for the end users computer, not the server. The toISOString and toUTCString functions will not apply the offset - they print the actual UTC value stored in the Date. This will probably still look "wrong" to you because it won't match the value you see in the console or when calling toString.
Here's where things really get interesting. You can create Date's in javascript by specifying the number of milliseconds since the Unix epoch using new Date(milliseconds) or by using a parser with either new Date(dateString). With the milliseconds method, there's no timezone to worry about - it's defined as UTC. The question is, with the parse method, how does javascript determine which timezone you intended? Before ES5 (released 2009) the answer was different depending on the browser! Post ES5, the answer depends on how you format the string! If you use a simplified version of ISO 8601 (with only the date, no time), javascript considers the date to be UTC. Otherwise, if you specify the time in ISO 8601 format, or you use a "human readable" format, it considers the date to be local timezone. Check out MDN for more.
Some examples. I've indicated for each if javascript treats it as a UTC or a local date. In UTC, the value would be Jan 1, 1970 at midnight. In local it depends on the timezone. For OP in pacfic time (UTC-8), the UTC value would be Jan 1, 1970 at 8 AM.
new Date(0) // UTC (milliseconds is always UTC)
new Date("1/1/1970"); // Local - (human readable string)
new Date("1970-1-1"); // Local (invalid ISO 8601 - missing leading zeros on the month and day)
new Date("1970-01-01"); // UTC (valid simplified ISO 8601)
new Date("1970-01-01T00:00"); // Local (valid ISO 8601 with time and no timezone)
new Date("1970-01-01T00:00Z"); // UTC (valid ISO 8601 with UTC specified)
You cannot change this behavior - but you can be pedantic about the formats you use to parse dates. In your case, the problem was you provided an ISO-8601 string with the time component but no timezone. Adding the letter "Z" to the end of your string, or removing the time would both work for you.
Or, always use a library like momentjs to avoid these complexities.
Vanilla JS Workaround
As discussed, the real issue here is knowing whether a date will be treated as local or UTC. You can't "cast" from local to UTC because all Date's are UTC already - it's just formatting. However, if you're sure a date was parsed as local and it should really be UTC, you can work around it by manually adjusting the timezone offset. This is referred to as "epoch shifting" (thanks #MattJohnson for the term!) and it's dangerous. You actually create a brand new Date that refers to a different point in time! If you use it in other parts of your code, you can end up with incorrect values!
Here's a sample epoch shift method (renamed from castAsUtc for clarity). First get the timezone offset from the object, then subtract it and create a new date with the new value. If you combine this with toISOString you'll get a date formatted as you wanted.
function epochShiftToUtc(date) {
var timezoneOffsetMinutes = date.getTimezoneOffset();
var timezoneOffsetMill = timezoneOffsetMinutes * 1000 * 60;
var buffer = new Date(date.getTime() - timezoneOffsetMill);
return buffer;
}
epochShiftToUtc(date).toUTCString();
In my file HomeComponent.ts (not in template html). I create a new Date and show it in console like this:
var fecha = new Date();
console.log(fecha);
the time in my country now is 16:09 (UTC -3) but the console output shows the date in UTC:
Date 2018-12-20T19:09:32.910Z // the time is 19:09
I need to compare and do some operations with "this new date" and other dates saved in a DB so I need the new Date to be created in my local timezone. How can I create a new Date in my local timezone?
How can I create a new Date in my local timezone?
Dates don't have a timezone, they are simply an offset from 1970-01-01T00:00:00Z (a time value) so are effectively always UTC. They represent a particular moment in time and can be used to generate a string representing an equivalent date and time in any timezone.
The local offset comes from the host system, it's used (if necessary) when creating a date and when working with local date and time values. There are equivalent UTC methods for doing operations that don't consider the local timezone.
The default toString method will generate a timestamp for the host timezone, toISOString will use UTC, toLocaleString can be used to generate a timestamp for any timezone. All will represent the same UTC date and time, just in different timezones.
When comparing dates, it's the UTC time value that is compared as it provides a common factor for all dates.
the time in my country now is 16:09 (utc -3) but the console output show the date in utc
A Date or DateTime is a structure, it does not have a format. If you want to display a formatted date string using the timezone of the browser then call toLocaleString.
var fecha = new Date();
console.log("As ISO8601 in utc:", fecha);
console.log("As local:", fecha.toLocaleString());
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.
I'm trying to compare two dates in javascript which are formatted differently. Namely:
2015-09-30T00:00:00 and 9/30/2015 12:00:00 AM
The former is UTC and the latter is not in UTC format. Logically, I am referring to the same date/time here but I can't come up with a way to compare them that will return true. Creating a new Date object with each ends up with different results (due to UTC offset with my local time zone).
What am I missing?
Ended up concluding that tagging on a "UTC" to the second date format before creating the Date object leads to an output consistent with the UTC formatted date.