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.
Related
I have timestamp in milliseconds which I want to convert to human readable format as it is.But moment js convert the timestamp as per the server's timezone. In fact, the timestamp is already in UTC timezone only. moment js converts it again to UTC. How to inform moment js that the given timestamp is already in UTC and not convert it again based on server's timezone.
Please consider the given code:
moment(parseInt('1561407163043')).format("LLLL")
Use moment.utc
moment.utc(parseInt('1561407163043')).format("LLLL")
See https://momentjs.com/docs/#/parsing/ for more details
Sounds like you need to lock the offset to insure its the timezone you parse is on a GMT offset of your choice. If I understand correctly, I had a similar case where my resource had data on its server's time, but my client server had its own time and when I ran reports, I had to decide what time to use based on the logged time and my decided offset.
https://momentjs.com/docs/#/manipulating/utc-offset/
I am using new Date(<date-string>) and then .getTime() to pass date strings to milliseconds from 1970.
The problem is that the date strings does not contain the timezone on them. They are British, so the timezone will be GMT or GMT+1 depending on the date...
When I use this technique in the front-end (Chrome), or in the back-end (Node.js). The time zone taken is the British one (GMT or GMT+1 depending on the date). I assume that is taken from the OS.
However, when using a Node.js server which I have been told is configured to be in UTC... the timezone is always going to be GMT, leading to errors during the British Summer Time.
Is there any way to tell Date to take the timezone from the OS without changing the server configuration?
Example:
var aDate = new Date('2016-06-23 10:15:0');
var timestamp = aDate.getTime();
Just in case my explanation is not clear:
// Executed on 28-06-2016
// In the browser (in London)
new Date().getTimezoneOffset(); // -60
new Date('28-06-2016 11:11:11').getTimezoneOffset(); // -60
new Date('28-01-2016 11:11:11').getTimezoneOffset(); // 0
// In the Node.js server I am forced to use, which is configured to use UTC
new Date().getTimezoneOffset(); // 0
new Date('28-06-2016 11:11:11').getTimezoneOffset(); // 0
new Date('28-01-2016 11:11:11').getTimezoneOffset(); // 0
// Ideally, I would like to have the output I get in the browser when I run the code in the UTC Node.js server
I recommend using Moment Timezone for this, since this would be needlessly complicated to implement without a library. To get UTC in milliseconds from a given date in a given timezone, you can do this:
const moment = require('moment-timezone');
function londonTimeToUTC(dateString) {
return moment.tz(dateString, 'DD-MM-YYYY HH:mm:ss', 'Europe/London').valueOf();
}
console.log(londonTimeToUTC('28-06-2016 11:11:11')); // 1467108671000
console.log(londonTimeToUTC('28-01-2016 11:11:11')); // 1453979471000
The second argument passed to moment.tz() is a format string, which is necessary if the date string is not in ISO format. The third argument is any valid timezone identifier.
Is there any way to tell Date to take the timezone from the OS without changing the server configuration?
The time zone from the OS is what the Date object uses. If you're asking if you can change that time zone without changing the configuration, then no - there is not a way to do that. The Date object always takes on the behavior of the local time zone. Even if you supply an offset in the input string, it just uses that to determine the internal UTC timestamp. Output via most of the properties (including toString and getTimezoneOffset) will always use the local time zone.
Even in your examples, you cannot count on the browser behavior always returning the values you showed, simply because each user visiting your web site may have a different time zone setting.
The recommended way to deal with this is by using the moment.js library, which can handle UTC and local time by itself, but may require use of the moment-timezone extension if you are wanting to work with a specific time zone, such as Europe/London.
Now, with that said, if you're certain that your entire node.js application will run in a single time zone, and you're running on Linux or OSX (not Windows), then you can indeed change which time zone that node.js considers to be "local". Simply set the TZ environment variable before you launch node, like this:
env TZ='Europe/London' node server.js
There is no equivalent for the browser, or for Windows. And you still have to contend with possible non-UK users on your web site - so this doesn't guaranteed a match between client and server time. But it does address your question.
See also:
How to initialize javascript date to a particular timezone
How to make the timezone of date to UTC
How to set default timezone in Node.js
This code compares 2 time - present time and a deadline time.
// Get current date/time
var now = new Date();
// Set up deadline date/time
var deadline = new Date(); //deadline is 1830hrs;
deadline.setHours(18);
deadline.setMinutes(30);
// Check if the current time is after the deadline
if( now > deadline ) {
console.log('after deadline');
}
else {
console.log('before deadline');
}
It works on my local machine where now and deadline are in the same timezone. What if the code is run on a server where the now timezone can be different from the deadline timezone to be compared? How to handle the situation when now can be any timezone and deadline is in, say, the Asia/HongKong timezone?
EDIT: Is there some way to specify the timezone when creating deadline? I think this is a possible solution.
As you creating both time in JS which the client side there will be no such case. because both time will read time from the same client.
But if in any case any of the time comes from server (in form of string of course )which located in another time zone and client is in another time zone then there is a possibility to this case happen.
Now you approach will be to convert both date to a specific time zone (any).
Then make the comparison.
You can use This Library to convert time zone in JS.
And take help from This Thread.
deadline and now are always in the same timezone because you new Date() there.
You are missing the information in what timezone the client is. This is partially solvable by just comparing it with the times form all the timezones.
In my example I will use moment.js because it is a nice library with a lot of features just for timezones.
You can use this code to find matching timezones, but sometimes they have different rules about DST and such so they will divert over the year.
However if that's fine you can now use moment.js to specify the timezone of deadline and calculate how much time you have left.
I am working on a platform that has users from all over the world, but certain settings are bound to a predefined timezone datetime.
What does this mean? If a user connects from a different timezone the app should still show him the current time in the predefined timezone regardles from where he logs in. I need to calculate this on the client side with javascript with only the timezone string.
What I would like to do is something like this:
new TimezoneDate('timezone');
and the result should be the current datetime for that timezone.
I know there are JS libs that handle this but I am asking if there is a simple JS solution without using external libs?
Depends on your definition of simple; but not really. Javascript does not have support for timezones out of the box. I would highly recommend Moment Timezone http://momentjs.com/timezone/ since it is very user friendly. I am also in the middle of a project with the same requirements and this library has made my work a lot easier.
Edit:
With the library, doing what you want is as easy as:
var timezonedDate = moment.tz('YOUR TZ STRING').toDate();
You can try:
var offset = new Date().getTimezoneOffset();
Or to get the difference in hours:
var x = new Date();
var currentTimeZoneOffsetInHours = x.getTimezoneOffset() / 60;
Mozilla Reference
The time-zone offset is the difference, in minutes, between UTC and
local time. Note that this means that the offset is positive if the
local timezone is behind UTC and negative if it is ahead. For example,
if your time zone is UTC+10 (Australian Eastern Standard Time), -600
will be returned. Daylight saving time prevents this value from being
a constant even for a given locale.
I'm working on a personal project involving Javascript, and as part of that project, I want to grab the current date (including time) and display it accordingly. No big deal right? Well, the deal is that I want to return the time & date in Eastern Daylight TIme, no matter where in the world the IP is.
If this is not possible, what alternative methods do you suggest? Does php have this functionality? I could write a simple php script that takes a date and converts it, but I want to keep this in JS if at all possible.
I'm trying to think through the best way to do this, but I'd appreciate any help that you could offer.
Thanks!
I found this on the internet, and there are a lot more of these scripts:
function calcTime(offset) {
// create Date object for current location
d = new Date();
// convert to msec
// add local time zone offset
// get UTC time in msec
utc = d.getTime() + (d.getTimezoneOffset() * 60000);
return new Date(utc + (3600000*offset));
}
So, you get the current time, add the offset of the current location to get UTC time and then you return a new date where you add the offset of a certain time zone again.
JavaScript native Date objects only know two timezones, UTC and the user's locale timezone (and even then, the amount of information you can extract about the locale timezone is limited). You could work in UTC and subtract 4 hours to get EDT, but do you really always want EDT and not EST?
If you want to do timezone conversions between arbitrary regions in PHP you'll need to drag in a large library with its own timezone information, such as TimezoneJS.
It may be better to keep the JavaScript stuff all in UTC, and let the PHP side worry about formatting it for a particular locale/timezone, using eg the timezone stuff from Date/Time.