I am trying to use UTC wherever possible. Now I found the following strange behaviour and I really don't understand what ist happening. It would be great, if someone could give advice.
Note: I write my code in the Google Apps Script Editor.
I use the following code to create a date and get the output in my local timezone:
var testDate = Date.UTC(2022,0,1,0,0,0,0);
Logger.log(Utilities.formatDate(new Date(testDate), 'Europe/Berlin', 'dd.MM.yyyy hh:mm'));
The result is 01.01.2022 01:00, as expected, because 'Europe/Berlin' is 1 hour behind UTC. So if I wanted the output to be 01.01.2022 00:00 I would try the following:
var testDate = Date.UTC(2021,11,31,23,0,0,0);
Logger.log(Utilities.formatDate(new Date(testDate), 'Europe/Berlin', 'dd.MM.yyyy hh:mm'));
But the result I get is: 01.01.2022 12:00
Can anybody hint me to why my expectation is wrong?
(I hope my English is okay.)
I don't think we can directly answer the question, because it looks like the issue is that Utilities.formatDate uses 12:00 for midnight (which is one of two valid ways of writing midnight in many systems, especially when using a 12-hour clock, though usually you follow it with something indicating it's 12:00 a.m., not 12:00 p.m.). For instance, here's an example of another formatter doing that because I'm explicitly telling it to use 12-hour time:
const testDate = Date.UTC(2022,0,1,0,0,0,0);
const dateTimeFormat = new Intl.DateTimeFormat("en", {
hour12: true,
timeZone: "UTC",
timeStyle: "short",
}).format;
console.log(dateTimeFormat(testDate));
So you'd have to look at Utilities.formatDate to see if it has an option for 24-hour time or at least using 00:00 for midnight, like some other formatters do.
But more fundamentally, if you're trying to format in UTC, I wouldn't play offset games to do it, not least because Berlin isn't always one hour offset from UTC, sometimes it's two hours offset (daylight saving time).¹ Instead, I'd have a formatter that uses the UTC accessors on Date (getUTCHours, getUTCMonth, etc.) to build the string rather than using the local time version. Either some library, or something that uses Intl.DateTimeFormat. For example:
const testDate = Date.UTC(2022,0,1,0,0,0,0);
const dateTimeFormat = new Intl.DateTimeFormat("de", {
timeZone: "UTC",
dateStyle: "medium",
timeStyle: "short",
}).format;
// Outputs "01.01.2022, 00:00", which is close to but
// not quite the same as your desired format
console.log(dateTimeFormat(testDate));
// Outputs your desired format, but may not be flexible across locales
const dateFormat = new Intl.DateTimeFormat("de", {
timeZone: "UTC",
dateStyle: "medium",
}).format;
const timeFormat = new Intl.DateTimeFormat("de", {
timeZone: "UTC",
timeStyle: "short",
}).format;
console.log(`${dateFormat(testDate)} ${timeFormat(testDate)}`);
¹ Remember that UTC is unchanging, it doesn't have daylight saving time.
Related
I am using Mongoose and Luxon to display a date, selected by the user from a form. But the date is console.logging one date, but displaying on the page as the day before.
This is my model:
const mongoose = require("mongoose");
const { DateTime, Settings } = require("luxon");
// Configure time zone
console.log(Settings);
const Schema = mongoose.Schema;
let AccomplishmentSchema = new Schema({
dateInput: {
type: Date,
required: true,
},
textInput: {
type: String,
required: true,
},
});
AccomplishmentSchema.virtual("dateInput_formatted").get(function () {
return DateTime.fromJSDate(this.dateInput).toLocaleString(DateTime.DATE_FULL); // format 'YYYY-MM-DD
});
module.exports = mongoose.model("Accomplishment", AccomplishmentSchema);
And this is my console log vs what is showing up on the page
dateInput: 2023-01-01T00:00:00.000Z,
textInput: 'etst',
December 31, 2022
etst
I can only assume this has to do with some kind of time conversion, but I've tried changing the time zone, and the settings, although I could've read the docs wrong. I cannot find a way to fix this issue.
When working with JS Date, the most important thing to understand is that Date doesn't store or know about a time zone. It simply stores the number of milliseconds since midnight on Jan 1, 1970 (aka UNIX epoch) in the UTC time zone. Then, when you call Date methods, the results are calculated for the current user's time zone (for methods like getMinutes()) or UTC (for methods like getUTCMinutes()). But the underlying data inside the Date is just a timezone-less number of milliseconds.
With that in mind, let's look at a simple example: new Date(0), which is equivalent to new Date('1970-01-01T00:00Z').
If your computer's time zone set to the Europe/Paris time zone, then when you call new Date(0).toLocaleDateString('en-US') then you'll get a result of '1/1/1970'. But if you change your computer's time zone to America/Los_Angeles and run the same code, you'll get a result of '12/31/1969'.
This happens because the Date's stored value corresponds to midnight on Jan 1, 1970 in the UTC time zone. In Paris that instant was 1:00AM on Jan 1, 1970, while in California it was 4:00PM on December 31, 1969. The same exact Date will print a different date depending on the time zone that's active at the time that date is printed.
Where this becomes particularly problematic is in cases where you're trying to express a date without a time. For example, assume you store a Date value of 2023-01-01T00:00:00.000Z in MongoDB.
When you display that Date in a date picker in a browser in California, the date shown will be Dec 31, 2022, because California is 8 hours ahead of UTC.
One way to solve this problem is to tell Date that the date you're using is a UTC date. Like this:
utcDateStoredInMongoDB = new Date ('2023-01-01T00:00:00.000Z');
// Get the year, month, and day in that Date, from the perspective
// of the UTC time zone.
year = utcDateStoredInMongoDB.getUTCFullYear();
month = utcDateStoredInMongoDB.getUTCMonth();
day = utcDateStoredInMongoDB.getUTCDate();
// Use that year, month, day to initialize a new Date in
// the user's time zone.
dateForDatePicker = new Date(year, month, day);
// Use that for your date picker.
dateForDatePicker.toLocaleDateString();
// => '1/1/2023'
// To go in the other direction, pull out the year/month/day
// in the current time zone, and turn that into a UTC date.
dateReturnedByDatePicker = new Date(2023, 02, 15);
year = dateReturnedByDatePicker.getFullYear();
month = dateReturnedByDatePicker.getMonth();
day = dateReturnedByDatePicker.getDate();
dateToStoreInMongoDB = new Date(Date.UTC(year, month, day));
dateToStoreInMongoDB.toISOString();
// => '2023-03-15T00:00:00.000Z'
Note that this all will get a lot easier in a year or so when the new JavaScript built-in date/time API, called Temporal starts shipping in browsers and Node.js. With Temporal, these kinds of problems are much easier because there's a dedicated API, Temporal.PlainDate for dealing with date-only values.
Luxon is working as intended and the display is correct. What is wrong is the data in your MongoDB.
Most libraries consider current time zone when you parse a date. I live in Switzerland.
const moment = require("moment");
console.log( moment('2023-01-01').toDate() )
> 2022-12-31T23:00:00.000Z
const { DateTime } = require("luxon");
console.log( DateTime.fromISO('2023-01-01').toJSDate() )
> 2022-12-31T23:00:00.000Z
const dayjs = require('dayjs')
console.log( dayjs('2023-01-01').toDate() )
> 2022-12-31T23:00:00.000Z
However, the native JavaScript new Date() constructor does not!
console.log( new Date('2023-01-01') )
> 2023-01-01T00:00:00.000Z
Maybe this behavior depends on your environment and scripting engine, I don't know.
You should also use Luxon when you parse the input data - don't forget to use .toJSDate() to convert the DateTime object back to Javascript native Date object.
Luxon uses the system time zone by default. You can change it:
const { DateTime, Settings } = require("luxon");
Settings.defaultZone = 'America/New_York';
If you don't care about the time, you can also use startOf('day')
Settings.defaultZone = 'America/New_York';
DateTime.now().startOf('day').toJSDate()
> 2023-01-13T05:00:00.000Z
DateTime.now().startOf('day').toISO()
> '2023-01-13T00:00:00.000-05:00'
We have a lot of data where dates are saved with the time component and these dates are saved from different time zones. For example, if we save "1st July 2022" in IST, in the database it is saved as "2022-06-30T18:30:00.000Z". But if we save the same date in EST, it is saved as "2022-07-01T04:00:00.000Z". Like this, we have data from a couple more time zones like the Central and Pacific timezone. Now the task is to show 1st July for all these time zones. Naturally, I browsed the internet for a solid foolproof answer, but couldn't get any. This one is the best I could come up with. But this is not foolproof. So need one logic that will work across any timezone.
const offset = yourDate.getTimezoneOffset()
yourDate = new Date(yourDate.getTime() - (offset*60*1000))
return yourDate.toISOString().split('T')[0]
You can use Date.toLocaleDateString() to show the date in the user agent's timezone.
Using a dateStyle of 'long' will show the date using a d MMM yyyy format, e.g. 1 July 2022.
function formatAsLocalDate(timestamp) {
const dt = new Date(timestamp);
return dt.toLocaleDateString('default', { dateStyle: "long" });
}
// This would be the date stored to the database...
const utcDate = new Date(2022, 06, 01).toISOString();
console.log('UTC date:', utcDate);
console.log('Local date:', formatAsLocalDate(utcDate))
.as-console-wrapper { max-height: 100% !important; }
Working with time zones can be tricky. It is best to use a JavaScript date library that can help you with date parsing, formatting and time zone translation.
It can be subjective as to which library to choose. I could recommend Day.js. Luxon is also very good (but has Monday as the first day-of-the-week which can't be changed).
An example with Day.js looks like the code sample below. The dayjs.tz.guess() function can be used to try to get the time zone from the user's browser.
import dayjs from 'dayjs';
import utc from 'dayjs/plugin/utc';
import timezone from 'dayjs/plugin/timezone';
dayjs.extend( utc );
dayjs.extend( timezone );
const YOUR_ISO8601_DATE = '2022-06-30T00:20:00.000Z';
const DESIRED_TIME_ZONE_LOCATION = dayjs.tz.guess(); // e.g. 'Indian/Mauritius';
let localDate = dayjs( YOUR_ISO8601_DATE ).tz( DESIRED_TIME_ZONE_LOCATION ).format( 'YYYY-MM-DD' );
As an aside: An UTC offset does not provide enough information for you to know how to translate a time from GMT to a desired time zone in a specific location. Time zone rules (e.g. when Daylight Savings Time/Summer Time begins and ends) are determined by governments rather than operating systems. A JavaScript date library along with use of IANA time zone database time zones (e.g. "America/New_York") could allow you to reflect time zone offset rules in your dates for specific locations.
I'm having trouble formatting the birthday date in the format 2021-04-13T00:00:00.000Z the date is sent correctly, but after this formatting it always has 1 day less. Can anyone help?
export function format(date): string {
const mydate = new Date(date);
return new Intl.DateTimeFormat().format(mydate);
}
Using the basic Date methods .getUTCYear(), .getUTCMonth(), and .getUTCDay() will enable you to get the date as it appears in your UTC-relative source string. As noted in a comment, your apparent date when rendered in your local time zone is one day earlier, as is correct for time zones west of UTC.
You can still make use of Intl.DateTimeFormat() if you pass in an option to use UTC as the time zone:
return new Intl.DateTimeFormat("pt-BR", { timeZone: "UTC" }).format(dateInput);
However, that's not supported by IE11 (if that's important to you).
I have a date I want to convert based on their timezone.
For example, I want to set it in EST time (America/New_York)
2019-04-24 12:00:00
and if the user comes across the site from America/Los_Angeles, it will appear:
2019-04-24 09:00:00
I need to be able to return the hour, so in that example: 9.
I tried using https://github.com/iansinnott/jstz to determine their timezone and https://moment.github.io/luxon in hopes of handling the conversion w/o any luck.
I was testing by changing the timezone on my computer w/o any luck.
It sounds like you're asking to convert from a specific time zone to the user's local time zone (whatever it may be). You do not need time zone detection for that, but at present you do need a library. (Answers that suggest using toLocaleString with a time zone parameter are incorrect, as that function converts to a specific time zone, but cannot go the other direction.)
Since you mentioned Luxon, I'll provide a Luxon specific answer:
luxon.DateTime.fromFormat('2019-04-24 12:00:00', // the input string
'yyyy-MM-dd HH:mm:ss', // the format of the input string
{ zone: 'America/New_York'}) // the time zone of the input
.toLocal() // convert to the user's local time
.toFormat('yyyy-MM-dd HH:mm:ss') // return a string in the same format
//=> "2019-04-24 09:00:00"
This capability is also provided by other libraries, such as date-fns-timezone, js-Joda, or Moment-Timezone, but it is not yet something built in to JavaScript.
Converting date based on the time can be done like this. reference convert date to another time zone example snippet is under.
var usaTime = new Date().toLocaleString("en-US", {timeZone: "America/New_York"});
usaTime = new Date(usaTime);
console.log('USA time: '+usaTime.toLocaleString())
var usaTime = new Date().toLocaleString("en-US", {timeZone: "America/Los_Angeles"});
usaTime = new Date(usaTime);
console.log('USA time: '+usaTime.toLocaleString())
You could keep a list of timzeone identifiers and a list of their corresponding +/- number of hours with respect to your local time (which is returned by your time function).
Once you have a user's time zone, and you have extracted the current hour from the local timestamp simply look up the timezone in your list and use it's index to access the second list to find how many hours to add or subtract from the users time.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleString
var date = new Date(Date.UTC(2012, 11, 12, 3, 0, 0));
// toLocaleString() without arguments depends on the implementation,
// the default locale, and the default time zone
console.log(date.toLocaleString());
// → "12/11/2012, 7:00:00 PM" if run in en-US locale with time zone America/Los_Angeles
Or you can use getYear, getMonth, getDate, getHours, getMinutes, getSeconds to format your own representation of the date. These methods all return values according to the user's local timezone.
I think the question may need more clarification - my first impression was you refer to a date-time that you already have and serve from the server. Doesn't this problem boil down to the Date object being "user-timezone-aware"? or not? But it is (some methods are, to be exact)
Your date/time is 2019-04-24 12:00:00 EDT (i assume P.M.)
This means the Unix timestamp of this in milliseconds is 1556121600000
(i assume daylight is on for April so not pure EST but EDT and an offset of UTC-4:00)
When you call
console.log(new Date(1556121600000).getHours())
doesn't this return 9 as you suggest, for Javascript executed on a browser from America/Los_Angeles with PDT timezone?
As suggested at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getHours :
The getHours() method returns the hour for the specified date,
according to local time.
I have this backend that sends me a pre formatted time in a set time zone, but without any information for the said time zone. The strings are like: "2013-08-26 16:55:00".
I can create a new moment.js instance with this string:
var time = moment("2013-08-26 16:55:00") //this creates time in my tz
but this will only create an instance in my own time zone.
Moment.js have a plugin that can create instances of the object in specific time zones and it works great, but I can't say what time I want the object to point to.
If I'm in New York and I do this:
var time = moment("2013-08-26 16:55:00").tz("America/Los_Angeles");
the resulting time will be 13:55 instead of 16:55 but in LA.
What I want is to create an instance that will say 16:55, but in LA time.
The reason I'm asking is because I want to do this:
var now = moment.tz("America/Los_Angeles");
var end = moment("2013-08-26 16:55:00"); //plus something to convert LA time
var timeLeft = end.diff(now, "minutes");
Is there a way to do that?
In most cases, you can simply do this:
moment.tz("2013-08-26 16:55:00", "America/Los_Angeles")
If you require input other than ISO8601, then specify the format string as the second parameter, and the time zone as the third:
moment.tz("8/26/2013 4:55 pm", "M/D/YYYY h:mm a", "America/Los_Angeles")
And if you need to use moment's "strict parsing" mode, then that goes in the third parameter, and the time zone moves to the fourth position:
moment.tz("8/26/2013 4:55 pm", "M/D/YYYY h:mm a", true, "America/Los_Angeles")
If you want to calculate everything in a specific timezone you want to set the default time zone using
A) moment.tz.setDefault("America/Los_Angeles");
For my use case (in a node.js project) I just set it right after requiring the moment modules like so:
let moment = require('moment');
require('moment-timezone');
moment.tz.setDefault("America/Los_Angeles");
All calls to moment() thereafter will create the time in the "America/Los_Angeles" setting, which is NOT the same as using:
B) moment.tz("2017-03-04 00:00", "America/Los_Angeles")
OR
C) moment("2017-03-04 00:00").tz("America/Los_Angeles")
both of which would create the moment object in UTC time (unless you already changed the default), and then convert it to be the Los Angeles timezone.
Running B or C above in the browser console yields:
_d: Fri Mar 03 2017 16:00:00 GMT-0800 (PST)
_i: "2017-3-4 00:00"
Notice _d shows March 3 4:00pm; this is because the moment object is created with March 4 12:00am in UTC time, then converted to Pacific timezone, which is 8 hours behind/the previous day.
source: http://momentjs.com/timezone/docs/#/using-timezones/default-timezone/
install moment-timezone
> npm install moment-timezone
Or see https://momentjs.com/timezone/docs/
.tz(string, string)
moment.tz("2020-01-02 13:33:37", "Iran/Tehran")
Just to make something abundantly clear, that is implied in other answers but not really stated:
You absolutely must either
use ISO8601 as your date format or
specify the format your string is in
.. when using the .tz(string datetime, [string format,] string zone) function, if you want moment to interpret the datetime argument you give to be in the zone you give. If you omit format, be sure to pass an ISO8601 formatted string
For 2 days I went round in circles, because my API was delivering a time string like "03 Feb 2021 15:00" and sure, it parsed OK, but it always used the timezone from my local machine, then converted to the timezone I gave:
//this always resulted in "2021-02-03 10:00 EST" if run on a machine in UTC
moment.tz("03 Feb 2021 15:00", "America/Indianapolis").format("YYYY-MM-DD HH:mm z")
This was massively confusing: the parsing was clearly working fine, because the date was right but the time was always wrong by however many hours there were between the machine and the given zone string
Switching to ISO format input worked:
//this always resulted in "2021-02-03 15:00 EST" if run on a machine in UTC
moment.tz("2021-02-03 15:00", "America/Indianapolis").format("YYYY-MM-DD HH:mm z")
As did declaring:
//this always resulted in "2021-02-03 15:00 EST" if run on a machine in UTC
moment.tz("03 Feb 2021 15:00", "DD MMM YYYY HH:mm", "America/Indianapolis").format("YYYY-MM-DD HH:mm z")
I hope this saves someone some time
I had a similar issue for which i had to use New York based time so i had to consider for daylight savings. I tried using the above few answers but wasn't able to get it working. Then I solved my issue like the below code
import moment from 'moment-timezone'
const time = timestamp
const offset = moment.tz.zone('America/New_York')?.parse(time)
const date = moment(time).add(offset, 'minutes').toISOString()
or you can do this way which will consider the time offset on its own when you display locally.
const time = moment.tz(timestamp, 'America/New_York')
const localtz = moment.tz.guess()
const date = time.clone().tz(localtz)
this gives you an ISO string which you can use as below
moment(date).local().format('dddd, MMM DD YYYY, hh:mm A')
or in whatever format you would like to display it