JavaScript Date Object

Cat

I tried to explain this to my boss the other day, and he didn't get it either: the difference between local time and UTC on one hand, and the timezone on the other, are two different concepts. Most countries don't span over more than one time zone, so they don't go around calling it a different timezone when the time changes. It's different for the U.S. because they span what, eight timezones? So it's understandable that they have lots of different names for times and then confuse those names for timezones. But AFAIK, New York City (which I believe is in the timezone you're talking about) doesn't suddenly up and move hundreds of miles, twice a year. It's going to be in the same location, and therefore in the same timezone, no matter what TLA you give the time.

The word 'time zone' is somewhat imprecise. In different contexts it could mean either a geographical region (for example, Arizona is in the Mountain Time Zone) or a UTC offset (Arizona is on Mountain Standard Time). They are two different concepts (one a physical location, the other a specification for time relative to UTC) but both are colloquially called time zones.

New York, as you mentioned, is always in the Eastern Time Zone (geographically) but at any particular day of the year, they will either count local time in the Eastern Standard Time zone, or the Eastern Daylight Time zone.

It's also complicated because even within (geographical) timezones, the local time is not always the same at all places. For example, even during summer, while most of the Mountain Time Zone is on MDT, Arizona is still on MST, except for the Navajo nation (located within Arizona's borders) that's on MDT.

sebastian.galczynski

I know, i'm engaging in necromancy, but I need to vent. After 10 years NOTHING changed, only now I have to engage with this retarded API not just in the browser, but on the server.

Simple thing: I have a table with something like opening hours. From date, to date, from hour, to hour, and timezone. Check if the shop is actually open now. Can't be fucking done in this retarded language without importing third-party library, because it has no notion of timezones (except the system timezone, which is set to UTC).

Ok, imported moment.js and moment-timezone. It's apparently semi-deprecated, but nobody settled on anything newer, so let it be.

Is there perhaps something like java.time.LocalDate? No, of course not. To get

LocalDate localDate = LocalDate.ofInstant(now, timezone);

I need to do n- not devine intellect stringly-typed things like this:

const localMidnight = moment.tz(d.toISOString().replace(/T.*$/, ''));

(or alternatively use 7 setters)

And why do methods double as getters and setters? Who thought this is a good idea?

m.day() // returns day of week
m.day(5) // sets day of week

By the way, why are there any setters? What happened to all this circlejerk about pure functions and immutability?

Ok, done. But now i have timezone data baked into javascript code, because of fucking course it can't use system's tzdata. If something changes (like the EU ditching daylight saving time), the poor customer will have to recompile the source with all those little npm modules. Good luck after 5 years.

Benjamin Hall

@sebastian-galczynski I feel your pain. And I'll add at least one more related to this (albeit from a 3rd party)--at least one library out there hard codes the onset dates for daylight-saving time to the current year's dates. Yup--if you ask for a date next year, the transition between DST and regular time will happen on the same date it does this year. Same for any other year.

jinpa

@Benjamin-Hall That's pretty impressive. The whole idea of putting out a library is because it handles the details that the programmer would rather not have to handle. If you don't have time to make it work right on such basic things as DST, why put it out at all?

What's the name of this library? Is it obscure, or fairly common?

Benjamin Hall

@jinpa said in JavaScript Date Object:

@Benjamin-Hall That's pretty impressive. The whole idea of putting out a library is because it handles the details that the programmer would rather not have to handle. If you don't have time to make it work right on such basic things as DST, why put it out at all?

What's the name of this library? Is it obscure, or fairly common?

I would have to look it up, we moved away from it hard once we realized. It was a significant one on NPM at the time.

Bulb

@sebastian-galczynski said in JavaScript Date Object:

After 10 years NOTHING changed

That's called backward compatidebility. It's still strongly preferable to gratuitous breakage of existing code.

@sebastian-galczynski said in JavaScript Date Object:

But now i have timezone data baked into javascript code, because of fucking course it can't use system's tzdata.

Well, because in many javascript environments it does not have access to them. ~~The standard Date does though, so it could just use it under the hood—Date is limited and somewhat weird, but it's not actually wrong.~~ And Date can only be constructed for globally configured local time-zone, but not arbitrary one, so it does not help much.

dkf

@Bulb said in JavaScript Date Object:

it's not actually wrong

Bulb

@dkf It is not actually wrong, but I was giving it much more credit than it deserves—while it must be using those timezone data under the hood, it does not grant any access to them beyond using them to convert specific timestamp between UTC and globally configured local timezone (which is the same extent of functionality as the standard C library).

Bulb

@sebastian-galczynski said in JavaScript Date Object:

because of fucking course it can't use system's tzdata.

This is actually true about most similar libraries in most languages, because while the operating system usually has those data, each system has different interface to access them and it is quite restrictive on some anyway.

dkf

@Bulb said in JavaScript Date Object:

This is actually true about most similar libraries in most languages, because while the operating system usually has those data, each system has different interface to access them and it is quite restrictive on some anyway.

The big problem is usually Windows. Other platforms tend to use the timezone database directly (differing mainly in where they keep it) but Windows does its own thing.

sebastian.galczynski

@dkf said in JavaScript Date Object:

Other platforms tend to use the timezone database directly (differing mainly in where they keep it) but Windows does its own thing.

Java has its own (it's a separate package on my system), but it's still part of the runtime.
PHP is curious, because it uses 2 different system libraries: "normal" tzdata (date(), DateTime) and ICU (IntlDateFormatter). I've seen a situation where these two differed (after Russia abolished DST), causing very funny behavior. But even then, it was fixable without touching the code, only the runtime.

pcooper

@sebastian-galczynski Well, there's at least a proposal now to have a better library built into Javascript:

GitHub - tc39/proposal-temporal: Provides standard objects and functions for working with dates and times.

Provides standard objects and functions for working with dates and times. - tc39/proposal-temporal

I have no idea how long it might be before one can actually use it, or if it's just going to end up swapping one set of pain points for another.

sebastian.galczynski

@pcooper said in JavaScript Date Object:

@sebastian-galczynski Well, there's at least a proposal now to have a better library built into Javascript:

GitHub - tc39/proposal-temporal: Provides standard objects and functions for working with dates and times.

Provides standard objects and functions for working with dates and times. - tc39/proposal-temporal

I have no idea how long it might be before one can actually use it, or if it's just going to end up swapping one set of pain points for another.

I'm sure after another glaciation they'll implement it.

dkf

@pcooper said in JavaScript Date Object:

it's just going to end up swapping one set of pain points for another

Always bet on that option.

Benjamin Hall

@dkf said in JavaScript Date Object:

@pcooper said in JavaScript Date Object:

it's just going to end up swapping one set of pain points for another

Always bet on that option.

Yeah. Annoyance is a conserved quantity. You can shove it around, hide it where it's not important for what you're doing right now, but it always exists.

Although...really...it's worse than that. Annoyance is like entropy. It at best can be preserved at the current level, but more often increases. It cannot be globally decreased within a closed system.

HardwareGeek

@Benjamin-Hall said in JavaScript Date Object:

within a closed system

That's why you should reject walled gardens!

Benjamin Hall

@HardwareGeek said in JavaScript Date Object:

@Benjamin-Hall said in JavaScript Date Object:

within a closed system

That's why you should reject walled gardens!

Down with the OGL 1.1! #OpenD&D ... oh wait, wrong thread.