You Don't Need Moment.js
github.com
github.com
This blog post lists which Java 8 classes replace their Joda Time counterparts:
https://blog.joda.org/2014/11/converting-from-joda-time-to-j...
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
> [From your comment in link]: The birthday will be wrong from the very start, because datepickers din't care about people can be born in some TZ and fill forms different TZs. Normally if you're only interested in date only, it doesn't matter if time part is off by hour or more hours. But if you live in Africa, then it could be whole day difference (because of how date will parsed).
I have trouble understanding your example - I am guessing you are sending UTC date including time of birth? Seems a little contrived. Maybe pick a better example (calendars or alerts and timezones?)
That said, I agree that trusting the browser implementation is mad. We still have clients accessing using IE8 (we just dropped support), Safari 7 (iPhone 4), and a fair number use Chrome 30/33 because that is the version the WebView is stuck on for Android 4.4.
Some of our users have the date on their computer set a week out (or more)!
Edit: just saw comment at end of your article "If your users enter birthdays with some kind of date picker, you probably suffer from this bug!". I think you just have a problem with your code: you would not use UTC date/time from a date picker, and you should either zero the time component or don't use Date internally when you just need a date - e.g. an input type=date naturally returns "yyyy-mm-dd".
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 when you do it). If you happen to store that as UTC, you might find some interesting outputs for people on the West coast if you convert back to a local (US/Pacific) timestamp. Specifically, you'll get 1999-12-31 21:00:00, and if you do this blindly and throw away the hour portion, you still get the wrong date.
When you want dates, you often really want to store just the date potion. Any time you want a date and time, you probably also want a timezone along with it, or at a minimum, you want to know what type of output your use case requires and handle it appropriately. Dates and times are one of those things that seems simple until you've had to deal with the details and encountered the problems enough that you always treat it with a bit of respect.
You can roll your own solution using Number for date, since Number can safely hold a 52 bit integer (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...) and if you avoid using 32 bit Unix epoch dates as you get a falsy value on 1/1/1970.
"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.
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.
Would that this be true! There are time zones as far ahead as UTC+14: https://en.wikipedia.org/wiki/UTC%2B14:00
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.
It comes down to the use case, not the data.
Some German (I suppose, based on the GitHub profile) had to write a UTC aware implementation and then others had to push them to realize the issue.
Seems time and other regional issues are really hard even for the geniuses at Google. (Yep, I honestly believe they're smarter than me, which makes this really confusing.)
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
Not supporting timezones is a valid design choice, but is so important and integral it should be the first item both mentioned by a library and used as criteria to decide whether it's a valid choice for those surveying libraries.
It's sort of like choosing a storage solution. Do you need persistent storage that can survive a reboot, or is something ephemeral that works only while powered good enough? Both have their places, but choosing the wrong one for your specific use case is usually very problematic.
It's not like the author can't have known this, moment.js without locales is listed right at the top on the moment.js home page (but left out of this list).
At a previous client, we only imported the locales they actually support, you don't need to import the whole lot of locales if you don't want to. When you don't need the whole lot, they're actually tiny.
Side-note, Chrome recently changed how it parsed dates breaking existing code (if you left the "z" off a ISO date), yes, that meant different browsers native date parsing wasn't consistent until recently. I forget exactly when it happened but I think it's was about a year or two ago. I think we ran into it because we were using .Net MVC which by default the serializers would spit out DateTime's without the Z and DateTimeOffsets with them. They changed it for newer versions.
Personally, working with future dates in the restaurant trade, the recent dogmatic approach to treating everything with ISO is frustrating. When humans say "meet at a restaurant on 27th Sept at 7pm" they don't, at all, mean it by timezone. A person in France doesn't want to see the booking show 27th Sept at 8pm. And storing it ISO is dangerous as timezones actually change.
Regarding local times, if it's always local, why worry about it? Just store it in "UTC" without conversion, with the understanding that it will never be converted. That's what the Postgres "timestamp without time zone" type essentially is.
It abuses the i18n api (by parsing the date out of a formatted string) to provide timezone support without shipping timezone data, which is pretty clever.
I think the bigger lesson, if moment's size is news to you (for those of us using webpack), is to install webpack-bundle-analyzer. It's loads of fun, if you like visualizations.
The API is pretty nice!
If a library is heavy, it is in their interest to organize it instead as a collection of submodules that can be depended on individually (IIRC, lodash does this) otherwise they risk people just not using their stuff.
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 was the only thing I really needed aside from the standard library, but I guess it would’ve been faster to import moment.js.
TL;DR: Goes way beyond standard formatting.
(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.)
My rule in code reviews is if you're basing/copying something from the internet, you better be able to explain everything it's doing, and if you're pulling a dependency you better be able to explain why we need it and why you think it's trustworthy enough to put in our application.
For example, a js-joda LocalDate is just a date without a time or timezone. This allows you to cleanly represent things like birthdays, anniversaries or holidays in an unambiguous way.
js-joda is also immutable which in my experience is more predictable and less error prone. With js-joda, "d.plusDays(366);" leaves d unchanged.
js-joda also has very good duration support.
Because it does not use the native Date implementation it is potentially more consistent across platforms. It is also has lots of tests.
If all you are doing is formatting a few dates, date-fns is probably sufficient and it is certainly smaller, but for more intensive manipulations of dates and times I think js-joda is well worth the size.
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.
A devDependency is not the same as a dependency.
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...
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 address any of that.
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 fish to fry, but eventually it certainly matters. There's a reason the modern web is so freagin slow, and only half of it is because of slow backend APIs.
For other devs? I bet they say that people on slow connections are not the target market. After all, a slow line will choke on all the ads used to pay for the site.
> I bet they say that people on slow connections are not the target market
That however... there's a LOT of data showing how every seconds count for things like ecommerce or news websites. And for actual B2B type apps, they likely don't have adds after you are logged in. We're gathering a lot of data on this internally, and customers care a -lot- about perf of things like CMSs, CRMs and other enterprisey apps.
The 2MB+ of bloated, unoptimised JS that you ship with your page that I need to parse and render before I'm allowed to see the 20kb of actual content _does_ interfere with my ability to use the page.
if you have lots of new users on mobile using slow cellular connections, big libraries like moment.js add up and can really hurt load times and make for a poor user experience. for circumstances like that, a developer might look at what are the biggest libraries in their vendor bundle and look for ways to reduce them via tree-shaking or find alternatives, that is if they are even aware of how slow their current bundle might be for mobile users. i think this is for that kind of use case, not only to offer alternatives to those who might need it, but also to raise awareness for those who develop on their desktop and don't engage with their app like most of their users do
If this is true, which I hope it's not, then I feel very sorry for anyone who doesn't live in a major first-world c̶o̶u̶n̶t̶r̶y̶ city and wants to enjoy the internet.
This is the exception, not the rule. I find it hard to believe at 99/100 JavaScript programmers are not working mobile or web applications, where 300KB matters, even if you do some sort of content hashing.
Our complex single page app is approximately 180kb gzipped (JavaScript files and a single html main page) - no html from the server except for reports.
Size is very important for first visit (lower delay loading files over cellular), and important for subsequent cached visits (mobile devices are slow to parse JavaScript).
Perhaps it's time to start reading about UX , browser JS parsing speed, how JS executes, etc.
Making your dev life easier is nice, but don't forget the end goal...
(Note: I'm not talking about those internal apps that have 10 users :p)
From users point of view, it's irrelevant what you use inside but how snappy things are.
Why is this the first metric that is always trotted out?