From what I understand, when you store a date:
const date = firebase.firestore.Timestamp.fromDate(new Date())
You are storing a date object in the local timezone. However, when I later read this date from Firestore using:
doc.data().date.toDate()
This gives me the date in UTC, instead of the local timezone. Is this the expected behaviour? Am I understanding this correctly? It seems like it would make more sense to retrieve the date in local time since the date you stored is in local time.
When you store a date (in Firestore) with
firebase.firestore.Timestamp.fromDate(new Date()), you are storing a
date object in the local timezone.
This is actually not correct: All timestamps in Firestore are saved in UTC. The timezone of the user who saved the timestamp is not saved with the timestamp value.
Is this the expected behaviour?
Yes, storing the value in UTC gives the maximum flexibility for the developer to display it as desired, depending on his specific requirements.
As a matter of fact, it's up to the developer to display it with the timezone he wants when displaying it in a frontend. For example, the Firebase console converts the UTC date the timezone to which your computer is configured.
Related
In my application there is a requirement to display date times in different time zones. All these timestamps are stored in the database in UTC.
If I send the UTC date time to client and display using JavaScript, it automatically converts it to the client's time zone.
For example:
//the string is what I receive from the server
var date = new Date('2019-05-03T09:30:00.000+05:30');
document.write(date.toLocaleString("en-US"));
displays 5/2/2019, 11:00:00 PM in the browser which is in the Central Time Zone.
What if I do not want this automatic change, and just want to display the date and time that I received from the server?
I know I can get the offset from the date object, but then I have to do additional processing to display the same value that I already got from the server!
I need to store datetimes in a mysql database.
These datetimes come from the browser, so users in the US, Europe or Asia or wherever will see their correct times.
In the browser, i have the following javascript code:
var d = new date();
var iso_date_string = d.toISOString();
// produces something like "2017-02-17T19:42:27.100Z"
I send this string to the server which runs PHP, and in my server code I have:
$date = date( "Y-m-d H:i:s", strtotime("2014-02-17T19:42:27.100Z") );
And then I insert this value in MySQL.
Everything works fine, except I don't get the exact time, there is a 1 hour difference between what I store in MySQL and the time I have on my computer.
I think this may be related to taking into account daylight saving times, but I can't find how to do it.
Please advise.
When you always send the UTC datetime to your server and let javascript convert it back when showing, the problem will not occur.
The PHP date will be affected by the Timezone information embedded in the php.ini file.
As far as mysql storage is concerned, you will probably want to use UTC or some other standard not affected by daylight savings to store your datetime in mysql. Then, regardless of which browser reads it, it should get converted back according to their local timezone information.
See this article for further reading:
Daylight saving time and time zone best practices
You can use getTimezoneOffset() to check if it's DST, because it corrects for DST.
I found this solution on
http://javascript.about.com/library/bldst.htm
Setting the correct timezone information in the php.ini file did the trick.
Thanks.
I have a DATETIME field in my table that is being displayed differently than what I'm returning.
To understand, here are the exact object fields I'm returning in my API:
However, when I'm using PostMan and looking at the results, the time is being changed from what I'm returning to this:
I don't understand what's going on. I'm trying to store the DATETIME in the database as UTC time, and then have it sent over to the client, where the client will convert it to local time.
Here's what the DATETIME dates looks like in the database:
You're not storing the dates in UTC time. "GMT-0400 (EDT)" means that they're being stored in Eastern time. The Z in the other results means UTC (or Zulu) time, according to this spec: http://www.ietf.org/rfc/rfc3339.txt
I expect that your MySQL installation has the default timezone set to the timezone that your box is in (https://dev.mysql.com/doc/refman/5.5/en/time-zone-support.html) so when you add a time without specifying the timezone, it's assumed it's in the default timezone. That is then being converted to UTC in your response, adding four hours to the time.
You should probably specify a timezone when adding information to the database, and/or change the default timezone for your database. There may also be another layer "helpfully" changing things, depending on the API you're using to access the database, so if there is relevant information about the API, you can add that to your question.
I have a website where dates are sent to and from the server using JSON.stringify(). If the client writes a comment it is sent to the server with a date string, which looks like this
"2013-09-21T04:00:00.000Z"
When the server gets the string I create a new date from the string
var server_date = new Date("2013-09-21T04:00:00.000Z");
This date variable is stored in a MongoDB. But when the client reloads the page the date string the client receives looks like
"2013-09-21T00:00:00.000Z"
And when I make a new date from this string on the client
var client_date = new Date("2013-09-21T00:00:00.000Z");
the date object is incorrect. Somehow when I set the client_date the date is set to 9/20/2013 rather than 9/21/2013. When running the server on my local machine this was never a problem. Currently the server is running on AWS so I'm assuming that this is somehow messing with the dates? But I don't understand how the client_date variable is set one day before the date specified in the string, regardless of the hours-min-seconds. How can I format my dates to fix this problem? Thanks!
Z means Universal Time Coordinated (UTC) or Greenwich Mean Time (GMT). Therefore, when it's 2013-09-21T00:00:00.000Z in Greenwich it's still the 20th of September west all the way to where your Client is.
When passing a date in javascript, that has a 00:00 time, to a webservice that is using linq to sql to access the DB, on some clients browsers, after the save, the date that was passed to the datetime column in the db now has a time that is no longer 00:00, some cases it is hours before midnight so the date is moved into the previous days date, other times it is hours before.
How do we always make the date save and not the time to the db?
This is using asp.net webforms and c# and asmx webservices and most queries are compiled.
It depends on the details of how the date is being encoded. At a high level though, you have to:
Make sure the timezone doesn't get wiped out when it's sent from client to server. That means, send it as either a date-only string, or as a date with the timezone preserved; not as a UTC date.
Make use of DateTimeKind (UTC or local) and/or DateTimeOffset on the server to ensure it is properly represented whenever you're sending/receiving to the client/database.
See also here: Linq to SQL DateTime values are local (Kind=Unspecified) - How do I make it UTC?
I'm guessing that the date and time on the client is important. In that case how about converting the date-time info to iso format before sending it to the server and also send the client's timezone offset as well.
var d = new Date
d.toISOString() // 2012-05-05T22:14:35.506Z
// or maybe jus
d.getTime() // milliseconds since jan 1st 1970 or thereabouts
d.getTimezoneOffset() // Timezone offset in minutes from UTC
This way you get the UTC date and time and the timezone offset as well, that is how many minutes UCT time differs from local time. For example Norway would have a negative offset (UTC-Norwegian time = negative).