3 ms·

Undocumented Undefined Behaviour, anyone?

by pif 1y ago

hnbad 1y ago
It's documented undefined behavior, really. Implementations are allowed to accept other input than ISO strings and interpret them how they like. The real "bug" in the example is 2025/05/28 being May 28th because the implementation ignores timezones for that format. The issue with `Date` is that it is based on the original `java.util.Date` class and inherits all of its problems: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Date.html https://docs.oracle.com/en/java/javase/21/docs/api/java.base... - this is also where the wonky zero-indexed month value comes from. Note that Java deprecated all versions of the constructor other than the one taking a millisecond value or nothing, which JS can't do for backwards compatibility reasons. Hopefully `Temporal` will solve these problems but how long that spec has been in the works should tell you how difficult this is to get right when anything you put on the web is forever.
- meekaaku 1y ago
  how about postgres style timestamp and timestamptz unless a timezone/offset is given, its considered plain date/time, not an epoch.
  - hnbad 1y ago
    `Temporal` has three main types for this: - `Temporal.Instant` is a timestamp, the equivalent of a millisecond epoch timestamp or a UTC ISO string. - `Temporal.PlainDateTime` (and `Temporal.PlainTime`, `Temporal.PlainDate`, `Temporal.PlainYearMonth` and `Temporal.PlainMonthDay`) is timezone-unaware (i.e. they don't represent an actual point in time unless qualified with a timezone, e.g. when you just want to reference a calendar date). - `Temporal.ZonedDateTime` is timezone-aware (i.e. what you usually mean when dealing with specific instants in time). There's also `Temporal.Duration` which represents a delta between two instants and can be used to perform date manipulation (e.g. adding exactly one day or year to a given instant). I guess in terms of Postgress, `Temporal.ZonedDateTime` and `Temporal.PlainDateTime` are similar to `timestamptz` and `timestamp`, `Temporal.PlainDate` and `Temporal.PlainTime` are similar to `date` and `time` (without a timezone) and `Temporal.Duration` is similar to `interval`. It's odd that postgres allows for `time` to have a timezone but I guess that's only meant to be used when storing an instant as a set of `time` and `date` rather than a single `timestamptz`. `Temporal.PlainYearMonth` and `Temporal.PlainMonthDay` seem like the odd ones out but they make as much sense as `Temporal.PlainDate` if you want to reference specific calendar dates/months with incomplete information. I guess for sake of completeness one could argue for a need to be able to specify a precision for `Temporal.Time` to distinguish between a reference to "8 am", exactly "8:00", exactly "8:00.0" and so on, but that use case seems a lot more niche than those solved by the additional date types.

Undocumented Undefined Behaviour, anyone?

by pif 1y ago

Undocumented Undefined Behaviour, anyone?

It's documented undefined behavior, really. Implementations are allowed to accept other input than ISO strings and interpret them how they like. The real "bug" in the example is 2025/05/28 being May 28th because the implementation ignores timezones for that format. The issue with `Date` is that it is based on the original `java.util.Date` class and inherits all of its problems: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Date.html https://docs.oracle.com/en/java/javase/21/docs/api/java.base... - this is also where the wonky zero-indexed month value comes from. Note that Java deprecated all versions of the constructor other than the one taking a millisecond value or nothing, which JS can't do for backwards compatibility reasons. Hopefully `Temporal` will solve these problems but how long that spec has been in the works should tell you how difficult this is to get right when anything you put on the web is forever.

meekaaku 1y ago
how about postgres style timestamp and timestamptz unless a timezone/offset is given, its considered plain date/time, not an epoch.
- hnbad 1y ago
  `Temporal` has three main types for this: - `Temporal.Instant` is a timestamp, the equivalent of a millisecond epoch timestamp or a UTC ISO string. - `Temporal.PlainDateTime` (and `Temporal.PlainTime`, `Temporal.PlainDate`, `Temporal.PlainYearMonth` and `Temporal.PlainMonthDay`) is timezone-unaware (i.e. they don't represent an actual point in time unless qualified with a timezone, e.g. when you just want to reference a calendar date). - `Temporal.ZonedDateTime` is timezone-aware (i.e. what you usually mean when dealing with specific instants in time). There's also `Temporal.Duration` which represents a delta between two instants and can be used to perform date manipulation (e.g. adding exactly one day or year to a given instant). I guess in terms of Postgress, `Temporal.ZonedDateTime` and `Temporal.PlainDateTime` are similar to `timestamptz` and `timestamp`, `Temporal.PlainDate` and `Temporal.PlainTime` are similar to `date` and `time` (without a timezone) and `Temporal.Duration` is similar to `interval`. It's odd that postgres allows for `time` to have a timezone but I guess that's only meant to be used when storing an instant as a set of `time` and `date` rather than a single `timestamptz`. `Temporal.PlainYearMonth` and `Temporal.PlainMonthDay` seem like the odd ones out but they make as much sense as `Temporal.PlainDate` if you want to reference specific calendar dates/months with incomplete information. I guess for sake of completeness one could argue for a need to be able to specify a precision for `Temporal.Time` to distinguish between a reference to "8 am", exactly "8:00", exactly "8:00.0" and so on, but that use case seems a lot more niche than those solved by the additional date types.