61–70 of 91 posts
Also worth noting that the mutable nature of moment can make things very confusing where as date fns is immutable and consistent.
Remember that unless building a calendaring system, all dates should be stored in UTC and only converted into a specific Timezone for presentation.
Earlier quoted context omitted.
Past time zones should only be a fairly specialist need: our front end code (SPA that is especially in the time domain) doesn't need to deal with past time zones. Then again, although our SPA is 100% JSON, we do all date and time processing at the server. Putting UTC times into our front end would require the front end to know too many business rules. > e.g. birthdays via a datepicker that constructs Date objects > […
The problem is that if you use a zeroed time component, but at some point it's assumed 00:00:00 (midnight), shifting timezones might mean that it shifts to the previous day. Even if you then truncate the hour portion before display, the date is wrong. For example, you use a datepicker at some point, and it stores 2000-01-01 00:00:00 in the US/Eastern time zone (because that's where you and the computer you're on are…
"using dates" therefore works out to "not caring about the time of day" and that reduces to "not caring about the time of day in the same timezone" since the same time of day in two timezones have a ~50% chance of being in different dates.
It really comes down to "does your application need to worry about time zones?" If so, then you probably need to treat this seriously, and getting help with that is good. If not, not.
Earlier quoted context omitted.
The problem is that if you use a zeroed time component, but at some point it's assumed 00:00:00 (midnight), shifting timezones might mean that it shifts to the previous day. Even if you then truncate the hour portion before display, the date is wrong. For example, you use a datepicker at some point, and it stores 2000-01-01 00:00:00 in the US/Eastern time zone (because that's where you and the computer you're on are…
Even just using dates can be a mess. At midday UTC everyone experiences the same date. The other 23 hours of the day, a varying proportion of people are experiencing a different date. "using dates" therefore works out to "not caring about the time of day" and that reduces to "not caring about the time of day in the same timezone" since the same time of day in two timezones have a ~50% chance of being in different dat…
In some instances, if you really only care about the day something happened, adding a time is just extra details to screw up. But if you do need need a a time, you very well may also need a timezone.
Earlier quoted context omitted.
The problem is that if you use a zeroed time component, but at some point it's assumed 00:00:00 (midnight), shifting timezones might mean that it shifts to the previous day. Even if you then truncate the hour portion before display, the date is wrong. For example, you use a datepicker at some point, and it stores 2000-01-01 00:00:00 in the US/Eastern time zone (because that's where you and the computer you're on are…
Even just using dates can be a mess. At midday UTC everyone experiences the same date. The other 23 hours of the day, a varying proportion of people are experiencing a different date. "using dates" therefore works out to "not caring about the time of day" and that reduces to "not caring about the time of day in the same timezone" since the same time of day in two timezones have a ~50% chance of being in different dat…
Would that this be true! There are time zones as far ahead as UTC+14: https://en.wikipedia.org/wiki/UTC%2B14:00
Earlier quoted context omitted.
I’ve picked up node and js more seriously recently, coming from .Net and C# and I’ve been wondering why people in my learning material are relying so much on third party libraries for very basic things. I’m probably a little old fashioned, but I didn’t even know moment existed and I’ve been fooling around quite a bit with JS dates recently. It didn’t take a long time to write the .ToString(dd-MM-yyyy) module, that wa…
I've definitely made my peace with it. Think of it this way: how much better is a bunch of imports than the slew of stackexchange copy-pasta you'd find in an old PHP app?
(moment.js supports a huge number of localizations, which is impressive and good for i18n. so in this case maybe it isn't directly comparable to copy&paste for anything but trivial use-cases.)
The lack of timezone support in the two suggested alternatives (date-fns, dayjs) means they're not real alternatives for any use-case as soon as you're operating in a country with any DST, https://en.wikipedia.org/wiki/Daylight_saving_time_by_countr... .
Modern browsers have built-in timezone support via window.Intl. It's actually pretty nice! One glaring omission in the spec: given (UTC instant, tzname), there is no clean way to get that offset for that timezone at that moment.
tzjs works around this omission. This saves a lot of bundle space. moment-timezone includes the whole tzdata dataset: https://bundlephobia.com/result?p=moment-timezone@0.5.21
When will JS engines ship with timezone data to not let a third party maintain it?
Packages still have their place, but the lack of a decent standard library will hurt us for decades to come (already is arguably).
[0] https://dxr.mozilla.org/mozilla-central/source/intl/icu/sour...
Earlier quoted context omitted.
I've definitely made my peace with it. Think of it this way: how much better is a bunch of imports than the slew of stackexchange copy-pasta you'd find in an old PHP app?
Think of it this way: how much safer is the slew of stackexchange copy-pasta, which might have at least been fully read. And it doesn't add another dependency that might steal your credentials or your customer's credentials in the future. (moment.js supports a huge number of localizations, which is impressive and good for i18n. so in this case maybe it isn't directly comparable to copy&paste for anything but trivial…
I really don't understand this... while yes, I might at some point be interested in reducing my bundle size, for 99% of developers out there, a difference in 300kb is just completely irrelevant. I choose my JS libraries because they are actively maintained, have well designed APIs (easy to use), are common enough to where newly hired developers already know them, and just generally make my life easier. This doesn't a…
300kb is half a second to load for someone with a 5mb connection (which is still quite common in a lot of the world...and even in parts of the US). It's also a LOT of crap to parse on a lower end computer. Repeat with a few libraries, and you're going to need a Flash-style progress part as your app loads. That's not exactly a great user experience. Doesn't really matter if you're building an MVP or if you have bigger…
Earlier quoted context omitted.
The problem is that if you use a zeroed time component, but at some point it's assumed 00:00:00 (midnight), shifting timezones might mean that it shifts to the previous day. Even if you then truncate the hour portion before display, the date is wrong. For example, you use a datepicker at some point, and it stores 2000-01-01 00:00:00 in the US/Eastern time zone (because that's where you and the computer you're on are…
Even just using dates can be a mess. At midday UTC everyone experiences the same date. The other 23 hours of the day, a varying proportion of people are experiencing a different date. "using dates" therefore works out to "not caring about the time of day" and that reduces to "not caring about the time of day in the same timezone" since the same time of day in two timezones have a ~50% chance of being in different dat…
Afraid not. Kiribati, Tonga, Samoa, and New Zealand might be in the following day - they all experience UTC+13. Kiribati and Samoa even experience UTC+14.