I just want a confirmation from the experts.
I still don't feel confident in what I believe to be the right way of storing and treating dates in such environment.
I'm developing a little app, just for italian users.
Basically, they can create a list of entries, each having a creationDate (I am just interested in the date part, time is not useful in my scenario).
So, the user enters in the "date" form field a date in this format: 22/06/2014 represents the 22th day of June of year 2014. Then, date is parsed like that:
entryData.dateEntry = moment( $(form).find('input[name=dateEntry]').val(), 'DD-MM-YYYY' ).toDate();
Finally, my entry model is added to a backbone.js collection and stored server-side by Node.js + Express in MongoDB.
Querying Mongo for entries, I see:
2014-06-21 22:00:00 +0000
which corresponds to "dateEntry" : Date( 1403388000000 ).
Googling around, I discovered that MongoDB doesn't have the concept of timezone. All dates are stored in UTC and the date object I created before had GMT+2.
But I'm really scared... how will I get back my local timezone's date the easy way?
Next, I'll display entry data in an underscore template, this way:
<%= moment(dateEntry).format('DD/MM/YYYY') %>
And... voilà! I get my local 'italian' date back: 22/06/2014.
Now, my question: is that the right way to go?
The process is: parse dates in local timezone => store in utc => retrieve dates in local timezone. Is it a common practice?
I also thought: can't I simply avoid using timezones and storing my local (italian) time as it was utc time (2014-06-22 00:00:00)? Is that so bad?
Yes, it's a common practise to store all timestamps in UTC, and then convert it to specific timezones in the outer layers. A lot of frameworks automatically do that for you, including Rails. Let's say if going forward you start catering to other timezones as well, you will not face any problems because your DB has UTC entries. You will be saved the overhead of timezone conversions.
In case you want to save only dates, you can do that as well, but I don't see any harm in the way you do it currently - save everything in UTC. I am not sure about node.js but there would be some setting where you can specify the timezone (of Italy), and all your conversions will happen automatically. You may find this thread useful:
How can I set the default timezone in node.js?
Related
In firebase cloud function I am using typescript and I am not able to get a solution to convert firestore time stamp human-readable formate currently it is showing as '063720731421.495000000'
How to solve this any idea?
A Firestore Timestamp just contains two values (seconds and nanosecond) representing an offset from unix epoch time. This is similar to the Date object that some platforms use to represent a point in time.
The Firestore APIs aren't going to do anything to help you format the date. There are lots of libraries out there for various languages and platforms that will format dates for you. It should be trivial to convert Firestore's Timestamp into something you can pass to one of these libraries. In fact, on many platforms, Timestamp has a method to convert it to a native Date object.
In the JavaScript environment, you can get a Date object by simply calling toDate() on the Timestamp. After that, a library such as moment.js can help you format it any way you want.
I'm developing a tennis matchmaking app where you can post a match and decide at what time and day the match is. I cannot figure out the best way to store time and date in mongodb. I want to be able to display time, use it for search queries and display in text form like "the match is in 1 hour" any suggestion? I was thinking to use moment but I still haven't figured out how.
You would store the date in the default ISODate format supported by mongoDB. It will have the date and the time on it. Once you have the records then you can query against them with $gt and $lt operators etc.
On the UI side you can use momentjs (or date-fns etc) to consume those dates and get the 1 hour from now etc. moment actually has build in humanize methods for that where date-fns has various distanceInWords etc methods.
This question already has answers here:
How can I store time-of-day in MongoDB? As a string? Give arbitrary year/month/day?
(1 answer)
Best way to store time of day in Mongoose
(1 answer)
How do I get the time of day in javascript/Node.js?
(9 answers)
Closed 4 years ago.
I've been trying since long to figure out the best way to store user-defined date and time in MongoDB using mongoose library. What I mean by user-defined is that it could be a date/time from future or past. I don't want to store time stamp or current date. In some cases, I just need to store Time in 24hr Format because of some calculations and in some cases, I just want to store Date.
I am using mongo and mongoose for the first time and its hard to find the correct way doing it. Although I have tried couple of methods which are as follows:
I stored the date and time in String format which is the easiest way of storing and retrieving I guess but the problem is I have to work alot in order to perform calculations and updating records back. Also, high chance of inaccuracy.
I tried the Date Schematype but almost everyother question & tutorial I found on goolgle/stack is just explaing the current date or timestamp problem.
I tried using it but then I encounter a strange problem like
I am posting Date data in this format through a Post service, Though I just need the time in this case but it was prompting me a format error which make sense as well so I decided to capture the date just to avoid it,
"wakeupTime" : "2018/05/08 04:30:00",
"sleepTime" : "2018/05/07 19:30:00"
This is how I am recieving and creating my data
wakeupTime : new Date(req.body.wakeupTime),
sleepTime : new Date(req.body.sleepTime),
But It is storing this data in db with its own values I am not sure why
"wakeupTime": "2018-05-07T18:30:00.000Z",
"sleepTime": "2018-05-07T09:30:00.000Z",
In schema defination I have my wake up time and sleep time like this
wakeupTime: {
type: Date
},
sleepTime : {
type: Date
}
I know that dates could be very tricky and hard to grasp in the first place and I am very much sure that I am missing some pieces of this puzzle. I would really appreciate any help which could lead me to a accurate solution.
I'm using IBM's Cloudant (CouchDB) data store. I'm planning on storing dates as integers in the format YYYYMMDD instead of JavaScript Dates. Is there any CouchDB functionality that I'd be missing out on by not storing them as JavaScript Dates? Any other reason I shouldn't do this?
I've read this SO Q&A: What's the best way to store datetimes (timestamps) in CouchDB? and from that there appears to be no objections to storing dates in any format. It doesn't answer what built-in functionality might be lost.
You wouldn't be losing any functionality as you would make the date useful by processing it in a Map function as either a Secondary Index/View, Search Index or part of Cloudant Query.
The only downside is that by formatting them as such, you make it more difficult on yourself to use the JavaScript Date functions to modify the date to needs within a Map function.
Storing it as a String is an option. Might be easier to handle this way than as an Integer.
I am pretty new to Solr and requires some help. Currently I am pushing all my logs to be indexed by Solr using Flume-ng and Syslog-ng. I would also like to index the date, but I keep on getting exception due to different time format.
Syslog-ng generates ISO date/time according to this format: 2013-12-24T10:36:24.0000+8:00 or in general YYYY-MM-DDTHH:MM:SS:ffffTZD but Solr is only accepting in Zulu time YYYY-MM-DDTHH:MM:SSZ.
Is there any way for me to create a custom Solr date parser so I can correctly parse the date/time. Google gave me no result of how to approach this.
Or is there any way syslog-ng can generates the date/time in format accepted by Solr?
Currently, as a workaround I had to set the servers to UTC and generate the date/time manually using the template. However, I would prefer not to set all servers to UTC since it can be in different timezone and I would like to keep it that way.