I've always been of the opinion that timestamps should be stored UTC datetime or unix timestamp on the server side and then displayed to the proper locale by the client's device. Is this not a good method?
It is not good enough. All the major browsers that I tried do not properly handle the timezone offset, as I discovered a few days ago (I put a more complete answer about this in a stackoverflow answer, but I don't know if putting the link would count as self-promotion so I will leave it out)
In short, the ES5 specs [1] say that
The implementation of ECMAScript should not try to determine whether the
exact time was subject to daylight saving time, but just whether daylight
saving time would have been in effect if the current daylight saving time
algorithm had been used at the time. This avoids complications such as
taking into account the years that the locale observed daylight saving time year round.
This means that if your country handled daylight saving differently in the past, converting the timestamp to string may give you a wrong answer (this would be the case of a number of european countries during WWII).
The spec has been improved starting with ES6 [2], but to my knowledge no browser has fixed the issue:
An implementation dependent algorithm using best available information on
time zones to determine the local daylight saving time adjustment
DaylightSavingTA(t), measured in milliseconds. An implementation of
ECMAScript is expected to make its best effort to determine the local
daylight saving time adjustment.
NOTE It is recommended that implementations use the
time zone information of the IANA Time Zone Database
http://www.iana.org/time-zones/.
A solution is to use a JS library that has its own timezone database.
It's good enough (and correct) to store unix timestamps. For displaying the date - your comment applies...
Unix timestamp refers unambiguously to single point in time. Interpretation of this point in time in different timezones is complicated but it's outside of it.
I agree that storing unix timestamps is a good approach.
My issue was with "then displayed to the proper locale by the client's device."
I mean, by itself it is ok, but in the case of a web client one cannot unfortunately just use the Date object and convert the timestamp to a human readable string.
There are some cases where you not only care about the exact time (unix timestamps are fine for this) but also the timezone in which it was specified. I work on an app where users specify "people in california should see this at 3pm PDT" and get confused when they reload the page and it has been switched to "6pm EDT".
As an aside, moment-timezone it a godsend for dealing with timezone discrepancies. I would pay money for it.
In short, the ES5 specs [1] say that
This means that if your country handled daylight saving differently in the past, converting the timestamp to string may give you a wrong answer (this would be the case of a number of european countries during WWII).The spec has been improved starting with ES6 [2], but to my knowledge no browser has fixed the issue:
A solution is to use a JS library that has its own timezone database.[1] http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.8 [2] http://www.ecma-international.org/ecma-262/6.0/#sec-daylight...