Hacker News new | comments | show | ask | jobs | submit login

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....





I wrote a tiny library, tzjs, for exactly this reason.

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

https://github.com/dynasty-com/tzjs


Seriously... It's not like timezone support is some esoteric interest in a Date/Time library.

No, but it does add quite a bit of complexity, and if it's done correctly usually requires not just a database of timezones, but also when and how they've changed over the years.

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.


And as date-fns doesn't support all locales, and moment.js without locale support is roughly the same size as date-fns, what was the point of this?

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.


Date-fns supports 46 locales currently, so it's not nothing.

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.


Because if you send it up to the client it's very easy to accidentally get it converted unless you constantly guard against it.

I've sent a PR to date-fns to add time zone support, but the maintainer doesn't seem to have much bandwidth to review it. In the meantime, I'm going with Luxon



Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: