In redux state tree How do we store dates ?
store moment objects in redux
store js date objects in redux
convert to ISO 8601 string and then store
Something better than these
ie,
state={
fromTime: action.payload.fromTimeMoment,
dateTime: action.payload.dateTimeEs6,
toTime: action.payload.toTimeAsString,
}
In our current project we have stored it as moment objects, still not sure if that was the right thing to do.
When dealing with dates I'd prefer to store as a unix format or ISO string. The reason for this is because I might want to save the state to the local storage for speed things up for second time users.
Keeping instances of other classes (or in this case moment) in the store, you might find some problems while serializing the state.
Using reselect you can create a moment instance to access the date value.
i would just format it to epoch or the ISO string you mentioned and store it, and if its needed again convert it back to whatever you need. its pretty redundant to store an object over and over
Related
When I save timestamp dates on firestore, it saves as a timestamp datatype.
But when I retrieve the data into React, sometimes it is retrieved as a timestamp and I can convert it to JS date using toDate() but other times is retrieved as {_seconds, _nanoseconds} and I need to convert it manually.
It seems very confusing. Is there a best practise about how to save and how to retrieve dates from Google Firestore?
Thanks
The only way to store dates in Firestore is through the Timestamp, you could store them through Strings, but it would be a huge pain to convert it back to Date so there really isn't any other better way to do it, unfortunately.
I need to store in the backend a date in the format yyyy-mm-dd;
I've initially used in the frontend a js Date() object to store it, and dropping the time and timezone info while sending it to the backend; but that caused a "timezone issue" when parsing back the yyyy-mm-dd string into Date();
even if it's possible to workaround that issue I was wondering if using a simple String wouldn't be better; is there any drawback that now I cannot see and so I should use a Date anyway?
Similar to other comments, I would also recommend sticking with Date instead of strings to prevent browser differences and for ease of use. One note is when setting the date, don't forget to account for day-light savings which might cause a database crash if not accounted for.
CSS-Tricks: Everything you need to know about date in javascript
Is there way I can update all the date field format existing in documents of couch db
change format from
DateTime : "07-29-2017 19:07:23"
to
DateTime : "2017-07-29 19:07:23"
There's no automated way to do this, aside from writing a script that updates each of your documents.
An alternative, depending on your exact situation, might be to use a view to manipulate the data as it's being read. The view could detect the existing date format, and if it's the old one, convert it before displaying the document.
This would change the way you query the data, though--you'd have to request the new view, which could obviously be a deal-breaker in some scenarios.
First, you need a way to apply a function to every document. To do so, I suggest that you use pouchdb-migrate.
Finally, you only have to define your function and integrate it into pouchdb-migrate. You can either parse the date and convert it or simply do some string manipulation.
What is the best approach for dealing with DST values when your web service accepts requests from different timezones than that of your server?
My webservice accepts date strings using the ISO8601 standard (2012-02-21T05:00:00.000-05:00)
I want to account for DST but don't want the overhead of maintaining or connecting to a database to get the DST for each request which comes in from a different timezone to my server.
One approach im considering is using the servers default DST settings and then for each request that comes in convert it to the same timezone as my server is in. Then when the processing is done , convert the string back to the timezone of the client and return. The conversion of the response data could be done on the server or the client.
Any suggestions?
You could also take a look at the XDate project for handling date objects in Javascript. It's quite similar to JodaTime (in Java). Very easy to use and semantic.
XDate project
Here's what I would do. Before you submit your data/time, parse the strings into a JavaScript Date object. Then call getTime() and submit that value. getTime() returns the number of milliseconds since the UTC epoch, so in effect, it normalizes your times. Then when you return data to the user, pass in your UTC millisecond value to the constructor of a Date object and display the time as you would. By default, it'll display in the user's timezone.
When I create a date in javascript it is in zulu, when I save it in my mongodb via mongoose it is transformed to UTC (its keeps the same time value, but the timezone is changed). I'd like it to stay in zulu when saved, how can I set this option in mongoose ?
thanks
MongoDB stores all DateTimes in UTC. Any local times you supply are converted to UTC when stored in the database. The recommended approach is to always convert DateTime values to UTC yourself before storing them in the database, that way you are in full control.
Resources:
https://jira.mongodb.org/browse/CSHARP-185
Dealing with how MongoDB stores DateTime when used with Service Locator Pattern