I am getting a JSON string back from a webservice. I have tested this same thing on the W3C Schools site too for our local machine.
The time I am getting back for both the service and the W3C site from the UTC string via Javascript is 2 hours ahead. Any ideas how to fix this or do I need to adjust for daylight savings, or something else. Thanks in advance.
If you are living in a GMT-2 zone, you should get UTC time 2 hours ahead. If that's the case and you want to get local date, here is your answer.
Convert UTC Epoch to local date with javascript
Related
I want to send design an API and send a Javascript Date() Object (including Time ) to a PHP Backend.
I have a solution with timestamp now:
//Javascript
new Date().getTime()
which return a number like: 1525094344392
and I send to my PHP Backend which converts it to a PHP Datetime Object:
<?php
$date = new DateTime();
$date->setTimestamp(1525094344392 / 1000);
This works, but there is no timezone set, so I am wondering if there is a better solution. I have not found a simple format in Javascript which both, PHP and Javascript, easily understand.
Please provide a code sample.
If you are sending this data across the world so that people can view it in different countries, if the code turns it back into date format, it will also set it to their browsers location....https://www.w3schools.com/js/js_date_formats.asp talks about this.
When setting a date, without specifying the time zone, JavaScript will
use the browser's time zone.
When getting a date, without specifying the time zone, the result is
converted to the browser's time zone.
In other words: If a date/time is created in GMT (Greenwich Mean
Time), the date/time will be converted to CDT (Central US Daylight
Time) if a user browses from central US.
I have a <input type="date"> field on my webpage and cannot understand why the value of this input changes when I send it via a HTTP POST request from the browser (using AngularJS) to the server (Java). Here is an example of what happens:
Date selected in browser via <input type="date">: Wed Jan 24 2018 00:00:00 GMT+1100 (AUS Eastern Daylight Time)
Date that appears on server when sent via POST request: 2018-01-23T13:00:00.000Z
It appears that, on the server-side, the value changes from the browser's timezone to UTC (in this case from Australia/Sydney to UTC).
How can I use <input type="date"> to just send the date portion of the value without having the timezones converted and dates messed up?
Failure
The Z on the end is short for Zulu and means UTC.
So 2018-01-24T00:00:00.000Z and 2018-01-23T13:00:00.000Z do not represent the same moment. They represent two different moments in history, two different points on the timeline, eleven hours apart.
If you are certain that pair of values were intended to be the same moment, then something went wrong. This is not an adjustment in time zone.
We cannot further diagnose the source of the error as we lack information.
What probably happens is your server converts it to it's local timezone.
Why it happens? To normalize your time.
Imagine situation where someone from UK sends date (for example 12am 2018.01.22), and then someone from US receives it, and it will show him exact same time, even if it's different time zone (different time for him).
What you want to do is to calculate timezones(webpage side), or if it's not something you want to achieve, try changing your servers time zone.
I was just wondering why the following code results in the value of 7 (august) on my node.js box, but not on my browser.
new Date(1378008000 * 1000).getMonth()
Is it not assuming Unix Epoch GMT timezone? What timezone would it be assuming and how should I be handling things like this?
Thanks.
getMonth returns the month in the local time zone, so it indeed depends on the settings in use.
If you want to have the month base on UTC time, use getUTCMonth and the rest of the getUTC* family.
I have a legacy web app that stores dates as a UNIX timestamp (seconds since the epoch 1970). Usually a timestamp like this represents UTC, however these timestamps are UTC-8. It doesn't look like it ever accounts for Daylight Savings Time (DST). I could convert it on the server to UTC and send to the client, but I would like to know if there is a javascript only solution.
Example Input:
1399335987
Example Output:
"2014-05-05T16:26:27-07:00" // Pacific Daylight Time (PDT)
The client should display the date/time according to their local machine. I looked into using momentjs but I could not find how to construct a date from a number without the number being UTC already. Is this possible?
Yes, it's possible given the unix timestamps are in UTC, with Moment Timezone (http://momentjs.com/timezone/)
moment
.unix(1399335987)
.tz('MST')
.format('YYYY-MM-DDTHH:mm:ssZ');
And you get
"2014-05-05T17:26:27-07:00"
Note here I'm using MST, and you should be able to use whatever timezone you want, via Timezone Data Builder (http://momentjs.com/timezone/data/)
Actually, by default, moment parses and displays in local time.
This means, only if you're in a different timezone (offset really) and still want to get the local time in MST, it's necessary to set the timezone as MST.
Otherwise, moment.unix(1399335987).format('YYYY-MM-DDTHH:mm:ssZ') is good to go.
I typed "date" in console...and I get Tue Sep 20 01:01:49 PDT 2011 ...which is correct.
But then I do this in node.js, and I get the wrong time.
var ts = String(Math.round(new Date().getTime() / 1000));
Output is: 1316505706, which is an hour behind.
#KARASZI is absolutely correct about the root cause: Unix timestamps are always UTC unless you manipulate them. I would suggest that if you want a Unix timestamp you should leave it in UTC, and only convert to local time if you need to display a formatted time to the user.
The first benefit of doing this is that all your servers can "speak" the same time. For instance, if you've deployed servers to Amazon EC2 US East and Amazon EC2 US West and they share a common database, you can use UTC timestamps in your database and on your servers without worrying about timezone conversions every time. This is a great reason to use UTC timestamps, but it might not apply to you.
The second benefit of this is that you can measure things in terms of elapsed time without having to worry about daylight savings time (or timezones either, in case you're measuring time on a platform which is moving!). This doesn't come up very much, but if you had a situation where something took negative time because the local time "fell back" an hour while you were measuring, you'd be very confused!
The third reason I can think of is very minor, but some performance geeks would really appreciate it: you can get the raw UTC timestamp without allocating a new Date object each time, by using the Date class's "now" function.
var ts = Date.now() / 1000;
The reason is that the getTime function returns the time in the UTC timezone:
The value returned by the getTime method is the number of milliseconds since 1 January 1970 00:00:00 UTC. You can use this method to help assign a date and time to another Date object.
If you want to fetch the UNIX timestamp in you current timezone, you can use the getTimezoneOffset method:
var date = new Date();
var ts = String(Math.round(date.getTime() / 1000) + date.getTimezoneOffset() * 60);
Note you can avoid this confusion by using a node.js package like timezonecomplete or timezone-js which have an interface that is much less error-prone for date and time manipulation.
date in console will return the server time, whereas using JavaScript on a webpage will return the client's local time.