Yeah a lot of these popular libraries - including Moment, Luxon, Day.js - commit the sin of using a single type of object for distinct concepts. Absolute time, civil time? Basically the same thing right? Just shoehorn them both in.
I can understand why JS' Date is the way it is, but Moment, and even more so Luxon and Day.js, have no excuses - Joda Time has been around since what, 2005?
The IANA timezone database does occasionally revise historical rules when relevant information comes to light. So you might have calculated that some historical figure died at such-and-such a time UTC (based on a documented local time), but actually that's inaccurate and you might not know because you haven't redone the calculation with the new rules.
> Most libraries implement timezone aware dates as an offset from UTC internally.
For what it's worth, the libraries that are generally considered "good" (e.g. java.time, Nodatime, Temporal) all offer a "zoned datetime" type which stores an IANA identifier (and maybe an offset, but it's only meant for disambiguation w.r.t. transitions). Postgres already ships tzinfo and works with those identifiers, it just expects you to manage them more manually (e.g. in a separate column or composite type). Also let's not pretend that "timestamp with time zone" isn't a huge misnomer that causes confusion when it refers to a simple instant.
I agree naming is kinda awful. But you need geo timezone only for rare cases and handling it in a separate column is not that hard. Instant time is the right thing for almost all cases beginners want to use `datetime with timezone` for.
> note that all OffsetDateTime instances will have be in UTC (have offset 0)
Is this not effectively an Instant? Are you saying that the instant it represents can be straight up wrong? Or are you saying that because it uses OffsetDateTime, issues are being caused based on people assuming that it represents an input offset (when in reality any such information was lost at input time)?
Also that page implies that they did it that way to align with the JDBC spec, rather than your assertions about misleading documentation.
Yeah you gotta watch out for those "Etc" identifiers, especially if you were thinking about exposing all the identifiers to your users wholesale. The file for them has this comment:
> POSIX has positive signs west of Greenwich, but many people expect positive signs east of Greenwich. For example, TZ='Etc/GMT+4' uses the abbreviation "-04" and corresponds to 4 hours behind UT (i.e. west of Greenwich) even though many people would expect it to mean 4 hours ahead of UT (i.e. east of Greenwich).
What happens if a country that's currently at the new UTC-12 anchor wants to move back an hour under that system? Are they forced to "wrap around" and move to the next day instead? Or do you move the anchor itself back (to UTC-13) just to accommodate them?
In addition, the Heisig method doesn't teach "meanings" at all, rather "keywords", which in many cases are only kinda sorta vaguely related to their respective characters' (fragment of) meaning. Either way, they're mainly useful as an "anchor" or name to refer to the character by, and in many cases might as well be arbitrary. The real purpose is just to turn an initially indecipherable blob that is a character into something recognizable (and writable, if you care about that). In general, you're not learning meaning to a useful degree until you start seeing or hearing (when you can associate pronunciation) those characters in context, as you imply. Yeah sure, with Heisig alone you'll be able to see 鸡 and know that it (most likely) refers to chicken, but characters like that are a relatively small proportion.
