12 ms·
Didn't find to much info on arithmetic support, although it is mentioned. However, I hate working with dates because many APIs make question about dates a slog
by raxxorrax 5y ago
Didn't find to much info on arithmetic support, although it is mentioned.
However, I hate working with dates because many APIs make question about dates a slog.
Consider the following for the poor people on the dark side of the planet (UTC + something). If any application only saves the date and not the time and you have dates like 2021-06-28T00:00:00 or something like that.
Now it gets saved in a DB as 2021-06-27Z23:00:00, because the user lives in UTC+1-land. It is correct but makes my blood boil and propably causes a lot of errors, even in apps that set their time zone correctly. How often have I seen implementations that just /(.*)T.*/ match the date and create a bug.
I have no solution for this, but I wasted too much time on problems like this. Such errors also notoriously evade unit tests...
This seems decent from a quick look. But let us be honest, it has to compete with moment.js, not with Date().
- rauschma 5y agoThe Temporal cookbook has more information on time arithmetic: https://tc39.es/proposal-temporal/docs/cookbook.html#arithmetic https://tc39.es/proposal-temporal/docs/cookbook.html#arithme...
- raxxorrax 5y agoThat looks very promising, thank you.
- rendall 5y ago> But let us be honest, it has to compete with moment.js, not with Date(). Moment.js is deprecated: "Moment.js is a legacy project, now in maintenance mode. In most cases, you should choose a different library." https://github.com/moment/moment/#project-status https://github.com/moment/moment/#project-status
- raxxorrax 5y agoTrue, but I think it will be some death of author kind of story. Nevertheless the handling has to be at least on a similar level.
- dstick 5y agoThat's only half the story. It's "deprecated" because it's done. There's nothing more to add, fix or improve in the eyes of the maintainer. What a nice place to end up in: _"We now generally consider Moment to be a legacy project in maintenance mode. It is not dead, but it is indeed done."_ https://momentjs.com/docs/ https://momentjs.com/docs/
- blowski 5y agoWow! Next time someone says "no piece of software is ever finished" I'll know where to send them.
- deleted 5y ago[deleted]
- paxys 5y agoYou skipped the line right after this which completely changed the meaning: > We recognize that many existing projects may continue to use Moment, but we would like to discourage Moment from being used in new projects going forward.
- dstick 5y agoFair enough, but the parent mentioned that without quoting this part. So I just posted the other half. Regardless, you’re right - new projects shouldn’t use it because of unknown future problems.
- rendall 5y ago> There's nothing more to add, fix or improve in the eyes of the maintainer. What a nice place to end up in What a strange thing to say. Baffling. It's deprecated because programming standards have changed, the team agrees with those standards and nevertheless feels it would be too much work to incorporate them. Not "there's nothing more to add" but "we choose to prioritize stability over new features"
- leotaku 5y agoNote that there exists a spiritual successor to Moment.js in Luxon[1]. The creator was a Moment maintainer and it lives under the Moment project umbrella. 1: https://moment.github.io/luxon/ https://moment.github.io/luxon/
- neals 5y agoAlso check out dayjs
- enlyth 5y agoI've been very happy with date-fns, picked it up after hearing good feedback from others: https://date-fns.org/ https://date-fns.org/
- trulyme 5y agoI found its interface inconsistent and unintuitive, especially compared to moment.js and day.js. Still better than Date though. :)
- spacehunt 5y agodate-fns's insistence on using the native Date object makes handling timezones horrible and error-prone though. Luxon is much better in this regard.
- mellavora 5y agoMoment is depreciated because all of its functions were moved to date-fns, which lets you import single functions.
- drenvuk 5y ago>Now it gets saved in a DB as 2021-06-27Z23:00:00 Why would you ever do this? Save it as a JSON date. coolDate.toJSON() would give a timezoned human parseable date. Just parse it back to the users locale with a built in Date constructor. You can do milliseconds UTC but someone like my younger stupid self would screw it up like most people.
- cbsmith 5y agoIf it's only a date, it probably should be days since the epoch.
- aljarry 5y agoBut starting from which timezone?
- ulrikrasmussen 5y agoIrrelevant for dates. Dates do not refer to a point on the global timeline.
- joelbondurant 5y agoDates ALWAYS have an implicit time zone.
- aljarry 5y agoWhat do you mean? In Auckland _right now_ it's Wednesday, 30th of June, while in Los Angeles it's Tuesday, 29th of June.
- deleted 5y ago[deleted]
- cbsmith 5y agoDates are set against calendar which in turn is set against hourly increments that are offset by local time zones. There is the infamous AoE or "Anywhere on Earth" time zone which can be used to say things like "we won't start until after the 16th Anywhere on Earth", meaning it will at least be the 17th in all timezones before the work gets started, but even in that case, you're referring to an implicit time zone.
- shadowgovt 5y agoThe real issue is that time is actually a complicated subject that everyone assumes is easy because it's so ubiquitous.
- sparsely 5y agoThe Temporal proposal is dramatically better than moment.js (and Luxon, the better version of moment). It accurately models a much wider range of time based concepts, and draws on (mostly just copies) the last 30 years of developments in this space from other languages (mostly Java)
- slaymaker1907 5y agoThe correct answer is that you should save it as 2021-06-28 with no time component. I get frustrated with KeyPass because it saves password expiration datetimes and not dates which is incredibly inconvenient when you go between timezones a lot.
- 015a 5y agoI've personally worked on issues stemming from this; situations where the date is important, but not the time, such as correctly reporting when it is someone's birthday. One of the earliest axioms we drill into programmers is "use UTC, use date-time types". Don't store dates as strings, use your database's DateTime type. If your database has a Date sans-Time type, use that. But many databases don't, and that's where the axiom starts breaking down, because its very natural to say "well, I'll use the next best thing, a DateTime type". But this is wrong! Its far, far better to simply use a YYYY-MM-DD string. I cannot stress how much better this is, but its not obvious why its better to someone who has had that axiom drilled into their heads, and has never ran into this situation before.
- jkaptur 5y agoYeah, "always use UTC" is overrated. It's useful for things that have happened, but quickly becomes unintuitive for things that will happen - including birthdays, meetings, ...
- mattmanser 5y agoIt can even become wrong for future dates. Always use UTC is a broken, bad rule for future dates, it only makes sense for things that have already happened. As for how it breaks, you have a booking for 8pm the day after the start of summer time. You stored the date/time in UTC. Government changes the start of summer time. Your database now thinks it's at 7pm because it uses UTC. Here's some examples: https://codeofmatt.com/on-the-timing-of-time-zone-changes/ https://codeofmatt.com/on-the-timing-of-time-zone-changes/ Also the EU is seriously debating getting rid of clock changes, and it comes up in the UK semi-regularly. Your database will not fix your bad data when that happens.
- mulmen 5y agoBut would using local time help in this case? For example, what if the future event is something like the solstice? It's usecase dependent so it seems like the application should deal with this, at which point persisting in UTC is still a reasonable choice.
- qwertox 5y agoThe user doesn't live in UTC+1-land. He lives in "Europe/London" or "America/Los_Angeles", because this way DST is also considered. I've settled with storing Zulu time and in a separate field the timezone offset of the event in seconds.
- chrisweekly 5y agoTangent: moment.js has been replaced by date-fns (and dayjs) as the modern alt to native Date().
- deleted 5y ago[deleted]
- beardyw 5y agoDates were invented in case anyone thought programming was fun.
- tomp 5y agoThe original mistake you did was let someone else handle the timezone conversion. You should probably always default to storing UTC-normalized timezoneless datetimes (there's of course a number of exceptions, but generally "an instant" in the past should be translated into UTC before being stored into the database... with future dates/times, it's more ambiguous, but in any case, you should be doing the TZ conversion yourself).
- mabbo 5y agoYes, this exactly. Use timezones when displaying something to a user and otherwise not at all, imho.
- nicoburns 5y agoThis falls down if the timezones themselves change. e.g. if DST was planned, but was then cancelled. You really want to store the original time with timezone as well as UTC.
- EMM_386 5y ago> If any application only saves the date and not the time and you have dates like 2021-06-28T00:00:00 or something like that. I literally just spent hours going around a code base fixing this exact problem. Our back-end is a legacy, 20+ year old database where it was decided to save dates without a timezone. console.log(new Date("2011-09-24")); is: Fri Sep 23 2011 20:00:00 GMT-0400 (Eastern Daylight Time) These dates were all "thought" to be EST, not UTC. Good times. More fun examples here: https://stackoverflow.com/a/31732581/154603 https://stackoverflow.com/a/31732581/154603
- brundolf 5y agoI used to work on a web application where showing correct time stamps was extremely important, so I set my system-wide time zone to Mumbai so that TZ-related bugs would be really obvious in testing
- dheera 5y ago> Temporal does not support parsing human-readable strings. Well shit, that's one of the biggest things I want from a time library. There are about 15 different forms of human readable string formats that various APIs give you in their JSON responses and if they don't solve that, they haven't solved the biggest pain point. I guess congratulations for not solving the problem and instead making Javascript even more complicated to use by introducing yet another incomplete date library that skirts around perhaps the most important feature and which millions of hippie JS devs will jump on the bandwagon to use.
- symlinkk 5y agoIf you’re parsing human readable strings to determine a datetime in your codebase you messed up somewhere. The user should select a datetime with a picker that uses a calendar and dropdown menus (no freeform text input). Everywhere from then on in your code you should pass it around using some standard, either as a UNIX timestamp or ISO8601.
- dheera 5y agoWell no, the problem is I very frequently have to interface with APIs that give me human readable time strings only. Those APIs were not written by top quality engineers and I often have no other choice or way to interface with those systems. Also you mention ISO-8601 but this document does not even describe how to input an ISO-8601 string.
- filoeleven 5y ago…until you’re working on an app for servicing companies, shipping departments, etc. where on some forms nearly 1/2 of the input fields can be dates. Then your users hate you because they can’t just tab > type > tab to enter a date. I agree with you on the rest though. And I would love to be able to enforce ISO 8601 for text entry of dates.
- mastazi 5y agoI use a calories counter app called MyNetDiary and I live in Sydney (UTC+10:00), if I want to change my calories budget I can only do it in the evening, or otherwise the change will apply to the previous day.
- mastazi 5y agoPS except from this one issue I'm a very happy customer, it's a great app :-)
- gui77aume 5y agoI had better luck with date-fns than with moment.js, from Chile perspective, better daylight saving time handling.