propose change in date format from number to native ISODate about meteor-user-status HOT 12 CLOSED

How would it be any different than doing the following?

{'status.lastLogin': {$gte: Date.now() }}

I thought about this, but I couldn't see any difference in storing things as native Date objects.

from meteor-user-status.

Technically results can still be the same, there's a discussion thread on meteor-talk too regarding this topic that I participated in. The guys recommended the native Dates too. https://groups.google.com/forum/#!searchin/meteor-talk/storing$20date/meteor-talk/jujlCBRI4X0/vgWJlgp5MEUJ

from meteor-user-status.

Okay, I'm listening. How do comparisons between native Date objects work? Do they still work between different timezones? What is the purpose of the timezone that is stored in the native date?

Why does one person say to store the timezone separately while the other person says the timezone is included in ISODate?

The other reason I decided to stick with integers is because of the time offset calculated by timesync. I wasn't sure how to do these diff operations with regular dates and it seemed that instantiating new dates constantly (because of the reactive time variables) would be much more inefficient than necessary. Any comments about that?

from meteor-user-status.

One benefit I see so far in the use of storing native dates is its auto conversion to the right timezone on the client side.

So on my meteor server it records as UTC. But when I load my page in Singapore and retrieve the date field stored, it accurately logs as GMT+8 Singapore time.

from meteor-user-status.

Oh and regarding the comment about storing timezone separately I think that's not required. As mentioned above all the dates in the meteor server just need to be stored in UTC. I think by default the *.meteor.com servers I'm using are already preconfigured to output UTC time when you do new Date() on the server side.

from meteor-user-status.

I thought the conversion to the correct timezone is determined by the browser. If I load up the timestamp in a browser as new Date(timestamp) it will display in local time, no problem.

If there is no need to store the timezone in the ISO Date then it doesn't seem to confer any benefits to using it (other than the mongo aggregation queries in the thread you linked.) The only other benefit that I see is you would get to store the timezone of client-generated timestamps, but that seems like an edge case.

from meteor-user-status.

true. well just a suggestion. cheers.

from meteor-user-status.

We can leave this open and see if anyone else wants to chime in about it. I'm open to the idea.

In my use cases the integer is far more convenient than the dates because I am measuring time differences and don't want to be using Date objects or moment computations unnecessarily. But I'm interested in hearing other use cases.

from meteor-user-status.

ok cool thanks!

from meteor-user-status.

It's always smart to store dates as Date objects. You can always use valueOf() to get the epoch back out and do the same math you're doing now, but when someone calls the value out, it won't just be an integer. It will be a date object. And that's more human, and thus what I think should be done. I agree with @geekyme

from meteor-user-status.

Hi @wraybowling, thanks for pitching in. I don't think anything you said points to an explicit benefit of using Date objects versus integers, but I'll keep it in mind. I don't see any method as being 'more human' than the other, though.

from meteor-user-status.

Hi @geekyme, new timestamps stored in the database are all native Date objects now. Let me know if you find any issues in this version.

Old timestamps are not automatically converted; you may want to do that yourself, but I'm not sure it matters because most libraries that use dates accept integers or native Dates interchangeably.

from meteor-user-status.