How deal with date of activities, considering that is a global system.

[cdorner]

I want be able to open an activity without worrying with datetime in another timezones.

The system should consider the timezone of the user and show the correct date/time for him.

[cdorner]

What I did was save the UTC time, and convert again to the local timezone every time it's shown.

[dyokomizo]

Usually that's the best way and be explicit in the persisted timestamps (i.e. keep the Z in the end https://en.wikipedia.org/wiki/ISO_8601).

[cdorner]

Interesting, actually we are using firebase and he stores the date as milliseconds.
We can change that to store the date as String and put the 'Z' I just don't know how he will deal with search and indexing.

I have this screen that shows the user all activities that is happening now or in the future, so ordering by timestamp is critical at this point.

[dyokomizo]

Are you using this functionality? https://www.firebase.com/docs/web/api/servervalue/timestamp.html
As long as we keep all timestamps at UTC in milliseconds since the epoch it wouldn't be a problem, but storing them as a plain number makes it impossible to see if there was timezone info.

[cdorner]

Nop, I calculate the UTC on the device. Something like that.

var utc = new Date(date.getTime() + date.getTimezoneOffset() * 60000);

Firebase.ServerValue.TIMESTAMP gets the timestamp of the server (actualy he gets a proxy to timestamp).

[dyokomizo]

For event timestamps Firebase.ServerValue.TIMESTAMP is better (we don't need to worry about clock discrepancies between clients and server). For date/times that are user inputs (e.g. the user wants to schedule some event for a certain date/time) then we should use the local time libraries.

We don't need to encode dates as milliseconds, we could use a direct representation of most significant to least significant part (e.g. 20151130200436123) it takes 17 digits for millisecond precision and a even a signed long can fit at least 18 digits. One advantage of this representation is that it's easily readable, parseable, and comparable. The problem of this scheme in JS is that it's larger than a the integer that can be safely[1] represented in a double (which is JS underlying single numeric type) so weird things would happen.

Going back to our problem I don't think having timestamps as numbers or strings would change much, it would probably be faster with numbers and if we're using Firebase.ServerValue.TIMESTAMP (IMO we should never trust event timestamps given by the client and always compute them on the server) than keeping everything as ms since the epoch would be more seamless and probably less error-prone (a single encoding for all purposes).

Also I totally recomend using moment.js for all date manipulations: moment.utc().valueOf() will get the moment, modify it to UTC and calculate the milliseconds since the epoch, giving you back a number.

1. https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER