91–100 of 141 posts
> Moment.js with the same modern API Moment.js objects are mutable [0], and this library's objects are ... immutable. [0] https://momentjs.com/guides/#/lib-concepts/mutability/
https://day.js.org/docs/en/plugin/bad-mutable
However it is discouraged as mutable dates often lead to less maintainable, harder to debug, code.
Earlier quoted context omitted.
At some point you will need to calculate how many leap years to account for and whether or not a leap second was introduced in between two arbitrary times. Time libraries can help you with that.
Exactly there is the same problem, to a lesser extend, when adding/subtracting years which is not trivial to do properly.
Earlier quoted context omitted.
Examples of essential complexity you have to worry about if you want your code to be correct, and even if you want to test/detect all issues that can/do come up: - https://infiniteundo.com/post/25326999628/falsehoods-program... - https://infiniteundo.com/post/25509354022/more-falsehoods-pr... In my experience engineers will often brush these sorts of things off as “edge cases”, but really all of these complexities ar…
I only see this being an issue storing times as strings. Why not store them as integers (like a Unix timestamp) or at least some standardized string format? The only reasonable use case I can think of where you absolutely need all this complexity is if you're rendering a calendar or something similar.
User: set an alarm in eight hours.
User: remind me to brush my teeth on November 21st at 8AM.
User: please note my doctor's appointment in two weeks at 10AM.
---
tl;dr It's not just an issue of storage. Managing time is hard. There are requirements that we, as humans, will intuitively find the right interpretation for, that computers will absolutely break their teeth on.
If you are considering switching to a (different) date library, I would suggest to hold off. ECMAScript is about to introduce a native date and time API that is much better than the current Date functionality. It may also make the need for a third-party date library obsolete (as long as you do not need to parse custom date formats). - https://github.com/tc39/proposal-temporal - https://github.com/tc39/proposal-tempor…
Instead of using something that works right now, you’re saying people should hold off for a few months, then start using a prerelease API?
Or as it is coming RealSoonNow(tm) perhaps start looking into polyfills as you are going to need one anyway for a story time at least to support LTS browser versions.
If you are considering switching to a (different) date library, I would suggest to hold off. ECMAScript is about to introduce a native date and time API that is much better than the current Date functionality. It may also make the need for a third-party date library obsolete (as long as you do not need to parse custom date formats). - https://github.com/tc39/proposal-temporal - https://github.com/tc39/proposal-tempor…
Instead of using something that works right now, you’re saying people should hold off for a few months, then start using a prerelease API?
The fact that it only took me a few hours to find these suggests there are plenty more bugs like these to find. The fact that these bugs have been open since the start of March with no movement on them suggests they aren’t too interested in correct behaviour (or perhaps they’re just your typical under-staffed open source project).
Maybe I just got super unlucky and ran into the only two bugs here… but it’s not likely.
Luxon and moment.js both handled these cases perfectly. If you’re looking to move from whatever you’re using now, and you can’t wait for the new standard, I’d pick one of those.
I never use any date library and I never had a problem with it. I just use what the native Date() object offers. Other devs always say "Just wait, one day it will fall on your feet". But this has been going on for many years, in which my software has served millions of users and nothing ever fell on my feet. I think the complexity of a library like this (423 files, 1433 commits, 53004 lines of code) would have create…
Can you write a one liner to give me the timestamp for start or end of current week, or month? How about a text representation of a difference between two dates? Relative date string (eg. “2 weeks ago”)? Date comparison between two dates that are in different time zones? Does your date calculations take leap hours and leap seconds into account? Date libraries make all these and many more operations a breeze, while ro…
And... it's a multi tenant system, where some organizations use Sunday as the start of a week, and some use Monday. And they all want to be able to switch.
If you need timezone support, be careful, there’s a few critical timezones bugs you can find in GitHub issues that made us switch to Luxon.
I have not used moment.js or other date libraries in a long while. But how does this compare to Luxon? ( https://moment.github.io/luxon/#/why )
The other reason I like DayJS over Luxon is the sheer number of plugins you can pull in to do various things. Like for example I was building an application where I had to build a weekly calendar form for a timesheet, the requirement was weeks start on Saturday and end of Friday.
In DayJS I was able to do this pretty easily by doing: dayjs().startOf('week').subtract(1, 'day') to get the start and then took the result and did res.add(6, 'days') to get the end. I'm not sure if Luxon has this type of functionality.
Lastly I like the plugin architecture rather than giving you everything up front. By default DayJS does not include any of those cool transformations like I talked about above, you have to pull them in as plugins from DayJS, this results in a bit more setup but smaller bundle sizes at the end of the day.
I never use any date library and I never had a problem with it. I just use what the native Date() object offers. Other devs always say "Just wait, one day it will fall on your feet". But this has been going on for many years, in which my software has served millions of users and nothing ever fell on my feet. I think the complexity of a library like this (423 files, 1433 commits, 53004 lines of code) would have create…
Examples of essential complexity you have to worry about if you want your code to be correct, and even if you want to test/detect all issues that can/do come up: - https://infiniteundo.com/post/25326999628/falsehoods-program... - https://infiniteundo.com/post/25509354022/more-falsehoods-pr... In my experience engineers will often brush these sorts of things off as “edge cases”, but really all of these complexities ar…