6 ms·

Totally a tangent but, don’t use moment.js! It inherits some of the parsing and other quirks from the awfulness that is the JS Date object, the mutability almos

Totally a tangent but, don’t use moment.js! It inherits some of the parsing and other quirks from the awfulness that is the JS Date object, the mutability almost certainly will lead to being bit by a couple of bugs before you actually internalize it, and the time zone support is kind of tacked on as an afterthought. I highly recommend js-joda, particularly if you’ll ever be computing/showing things to your users in different time zones. It actually treats dates and times rigorously, and has an api that makes it clear what kinds of operations make sense to do on a zoned vs local datetime and makes things like converting between timezones vs transposing them explicit and simple.

always_good 9y ago
I haven't tried it, but https://date-fns.org/ https://date-fns.org/ looks nice. For example, immutable API and just uses native Date objects.
- dcosson 9y ago
  Yeah it looks nicely simple & modular, but it probably works best in Node.js since your servers can all be in UTC. In general I see the appeal of using a small shim around a standard library thing rather than re-implementing something totally new, but JS Date is bad enough that you're better off staying away altogether. It's just hard to use correctly since there's no "timezone unaware" object available and it always assumes the local timezone, so users' browsers in different timezones treat them differently. Lots of seemingly simple things (e.g. a time + timezone input picker) are easy to mess up because you end up accidentally implicitly converting things to the local time.
cabaalis 9y ago
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?
- mnutt 9y ago
  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.
- mrighele 9y ago
  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. [1] http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.8 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-saving-time-adjustment http://www.ecma-international.org/ecma-262/6.0/#sec-daylight...
  - mirekrusin 9y ago
    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.
jazoom 9y ago
For some reason reading the API docs of js-joda gives me flashbacks to Java programming. Maybe it's all the "public static" stuff. Maybe it's that I can't immediately see how to do something useful. Some examples would be nice.
- spondyl 9y ago
  I'm guessing the name is a reference to Joda-Time which is a DateTime library for Java. Maybe you'd seen the name somewhere and your subconscious had reminded you, haha
  - jazoom 9y ago
    Yeah probably that too
armandososa 9y ago
Thank you for this comment. I've been suffering for JS Date quirks for a long time, and haven't found a solution that alleviates the issues I've been having. Looks like js-joda is exactly what I need. Link for the lazy: https://github.com/js-joda/js-joda https://github.com/js-joda/js-joda
gpmcadam 9y ago
Fecha is antother light alternative https://github.com/taylorhakes/fecha https://github.com/taylorhakes/fecha

always_good 9y ago

I haven't tried it, but https://date-fns.org/ https://date-fns.org/ looks nice. For example, immutable API and just uses native Date objects.

dcosson 9y ago
Yeah it looks nicely simple & modular, but it probably works best in Node.js since your servers can all be in UTC. In general I see the appeal of using a small shim around a standard library thing rather than re-implementing something totally new, but JS Date is bad enough that you're better off staying away altogether. It's just hard to use correctly since there's no "timezone unaware" object available and it always assumes the local timezone, so users' browsers in different timezones treat them differently. Lots of seemingly simple things (e.g. a time + timezone input picker) are easy to mess up because you end up accidentally implicitly converting things to the local time.

cabaalis 9y ago

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?

mnutt 9y ago
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.
mrighele 9y ago
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. [1] http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.8 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-saving-time-adjustment http://www.ecma-international.org/ecma-262/6.0/#sec-daylight...
- mirekrusin 9y ago
  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.

jazoom 9y ago

For some reason reading the API docs of js-joda gives me flashbacks to Java programming. Maybe it's all the "public static" stuff. Maybe it's that I can't immediately see how to do something useful. Some examples would be nice.

spondyl 9y ago
I'm guessing the name is a reference to Joda-Time which is a DateTime library for Java. Maybe you'd seen the name somewhere and your subconscious had reminded you, haha
- jazoom 9y ago
  Yeah probably that too

armandososa 9y ago

Thank you for this comment. I've been suffering for JS Date quirks for a long time, and haven't found a solution that alleviates the issues I've been having. Looks like js-joda is exactly what I need. Link for the lazy: https://github.com/js-joda/js-joda https://github.com/js-joda/js-joda

gpmcadam 9y ago

Fecha is antother light alternative https://github.com/taylorhakes/fecha https://github.com/taylorhakes/fecha