I have had a truly gnarly time trying to work with Date objects in javascript, which strike me as ugly and unintuitive.
I am getting back two objects from an internal API: one date string in the form of YYYY-MM-DD and one time string in the form of HH:MM.
What I want to do, in javascript, is to merge these into a UTC-formatted string of the form YYYY-MM-DDTHH:MM:00Z. I have been playing around a bit with the moment.js and moment timezone libraries, but I'm not sure how I might leverage these to complete this task.
I solved this thusly using moment timezone:
dateTime = date.concat(" ").time
dateTimeAdjusted = moment.tz(dateTime, timezone).format()
(where timezone was a variable that I had access to that contained the timezone of the given date and time.)
Related
My app (back-end in C# & front-end in Angular Materials) has a search screen allowing user to specify the date period using datepickers. The problem is that some of the users are not in UK while all the data they view has been created with GMT date. So if someone in Germany selects date 01/01/2017 in datepicker, my back-end reads it as 31/12/2016 23:00:00 resulting in incorrect search results.
Can someone advise me how to deal with this? I'd like to still use the Angular Material datepicker but be sure that I'm passing the date selected by the user. I know I can transform the date before posting it like this:
moment(myDate).format('MM/DD/YYYY'))
but I have a lot of cases like this and would prefer some generic solution.
For transmission and storage, I advise using UTC for everything. Only at the point of display should the time be converted to whatever locale the user has selected. Despite this being an old problem, running into time conversion issues is still quite common. Most places I've worked at will store everything as UTC timestamps or Unix epoch time with respect to UTC, that way there is no question what the meaning is anywhere in the system. If/when it needs to be rendered to something local, we do it on the client side.
For example, to get the local time converted to UTC as a string:
var noTimeZone = new Date().toUTCString();
-or-
var noTimeZone = new Date().toISOString();
Or, if you want a numeric value so you don't have to deal with funky format parsing between client/server, you can get the Unix epoch:
var unixEpochMS = new Date().getTime();
Mind you, Date.getTime() will return milliseconds rather than seconds. Also note that the Unix epoch is defined in terms of UTC. That is, any numeric value that is a timestamp is expected to be UTC. If you want a different timezone, you need to parse the value and then set the timezone to what you want.
Solution 1:
I think the solution is to get your user's timezone. You can use Javascript to get timezone from user's computer and send it to server with the request.
var d = new Date();
var tz = d.getTimezoneOffset()/-60;
tz will be 2 if user's timezone is GM+2
Soution 2:
You send and receive Unix timestamp. But then you need to convert the timestamp to readable date/time based on user's timezone.
Say I had an ISO date string with embedded timezone information, like "2016-08-22T13:30:00-07:00" (Here, the -07:00 specifies PST). I'm looking for an elegant way to determine what day of the week it will be in that timezone on that date and time. I've tried moment.parseZone(datestring).weekday() to no avail. How can I make moment think in terms of the timezone specified in the string, instead of wherever the server happens to be?
You can try moment(datestring).utcOffset(datestring).weekday(), check the docs for more explanation. Also there is a part of the documntation on weekday which describes it as locale aware I am not sure if it maintains the time zone of the date while converting or defaults to your local/server location, I usually uses moment.day(), if it suits your use case, you can use it instead of weekday().
I pick some date and time in javascript and then want to store it on server (.NET). Dates are supposed to be in future from the current moment (so they won't be before 1970).
Having read topics here on SO I learnt it's better to store date as a string and people suggest using Date.prototype.toISOString() or Date.prototype.toUTCString().
I've read that toISOString() is not available in IE 7. And I'd like to know other differences, when I should choose one or another function.
They're for different purposes.
UTC is the primary time standard by which the world regulates clocks and time.
ISO is standard format time. ISO also supports ms in its format.
So if you want to send data to the server, send the ISO, because ISO is the standard format:
var date = new Date();
sendDate(date.toISOString());
You can also use toISOString in IE7 polyfill.
I hope it will helpful to you.
Summary About toISOString() :-
The toISOString() method returns a string in ISO format (ISO 8601 Extended Format), which can be described as follows: YYYY-MM-DDTHH:mm:ss.sssZ. The timezone is always UTC as denoted by the suffix "Z".
Refer Below link for more information about toISOString().
Date.prototype.toISOString()
Summary About toUTCString() :-
The toUTCString() method converts a date to a string, using the UTC time zone.
Refer Below link for more information about toUTCString()
Date.prototype.toUTCString()
Always use .toISOString()
They give almost the same information, but in different formats. Here is what I get on my machine.
new Date().toISOString()
"2019-10-11T18:56:08.984Z"
new Date().toUTCString()
"Fri, 11 Oct 2019 18:56:08 GMT"
There are 4 reasons .toISOString() is more often what you want than .toUTCString().
A. More convenient sorting
When you sort alphabetically, the "2019-10-11T18:56:08.984Z" pattern of .toISOString() gives you the correct date order.
B. Millisecond precision
.toISOString() provides millisecond values, whereas .toUTCString() does not.
C. Any user can interpret correctly
The .toUTCString() value may be more familiar to human end-users, but only if the language settings are suitable for them. In contrast, the .toISOString() is the same regardless of language settings.
D. Reproducibly regeneratable by software
You can easily convert the ISO date string to a Javascript Date object, and then back again, regenerating exactly the same string. This is regardless of who gave you the ISO date string, where the server is, and where you are.
This is not automatically true for the UTC string. For example, if a second instance of your app system is running in a different time zone, or language, it's .toUTCstring() may use different numbers or words (respectively) to represent the same instant in time. It will be difficult for it to create a UTCString that matches what was made by the first instance of the app, since in general it will not know the language or timezone in which the first UTC string was produced.
I think nobody needs .toUTCString()
I don't know why `.toUTCString()` exists. Its word-heavy format makes it useless for internal storage of dates in your program, because it varies depending on your language and timezone setting etc.
So maybe it is to produce something nice to display externally for the user to see? Well, not really. Anyone who is not in the London time zone will not find it very helpful.
I live in London. And even I, even if I was writing an app purely for use by me, solely on my system, and only in my home, would still not want to use .toUTCString(). Because it is showing UTC (also known as GMT). London is not always on GMT. In summer, we move to GMT+1, so the .toUTCString() result would mislead anyone who didn't notice the "GMT" and do the time adjustment in their head.
If I wanted a natural-language time, to make non-computer literate users comfortable, I would construct it manually from parts, using a library like moment.js. If I wanted a quick-and-dirty solution, I would use .toString() which at least will move to Summer time when appropriate.
Using the Github API I get times which look like this "2013-11-05T21:41:37Z", I think the 'Z' refers to zulu time i.e. UTC. What is the easiest way to convert this time to local time, using javascript (taking into account summer time changes)?
moment is a great library for dealing with dates and times.
It supports parsing ISO date times.
new Date('2013-11-05T21:41:37Z') returns the user's computer's set timezone. It automatically converts it to local time for you.
I am trying to post a created date to an ASP.Net MVC controller without the date being modified by the serializer. I am looking for some kind of way to do this on the client.
The date is being constructed as follows:
var priceDate = new Date(name.split("-")[1], name.split("-")[0]-1, 1);
The date is valid and the problem is the serializer is adding the timezone offset which i don't want. The javascript date should be UTC but this doesn't seem possible.
This problem is expressed in different ways all over the place with all kinds of solutions that just seem way over the top. Is is possible to make a javascript date UTC or devoid of timezone information from the client?
There is toISOString() function which returns dates in standardized format and always does zero time zone.
Server accepts dates in local zone, so you need to do next date.ToUniversalTime().
So javascrript date.toISOString() equals to c# date.ToUniversalTime().