[Macha]

So in my use cases, there's three types of dates that matter:

1. Past dates. These can be stored UTC, and just rendered in the appropriate timezone as a matter of formatting.

2. Future non-human dates: e.g. the next execution time of a job that runs every hour. These can just be UTC

3. Future human dates: I care about the human selected timezone so that events happen on the wall clock time the user expects. The UTC time and UTC offset are meaningless.

So in cases 1 and 2, having a non-UTC date is not required, while for case 3, the only thing that UTC offset is doing is adding information that could be inconsistent or confusing.

e.g. If the concert is on at 2026-01-31T18:00:00[Europe/Dublin] , that's all that matters, whether that ends up being 2026-01-31T18:00:00+00:00 or 2026-01-31T18:00:00+01:00 is unimportant for whether the building is going to be open at the time. So the system failing to give customers on the day of the concert a countdown because `2026-01-31T18:00:00+00:00[Europe/Dublin]` has become inconsistent because e.g. the EU actually did go ahead and abolish DST is suboptimal.

[burntsushi]

For that specific use case, sure! But Temporal isn't for Macha's 3 use cases. Not all future datetimes are only concerned with civil time. Some are concerned with the precise instant in time. So how do you choose which one? There is no one universal right answer, so IMO, the right default is to reject.

But if you know your use cases and know you always want to adhere to civil time even if it means a change in the precise instant, then Temporal supports that too:

    >> zdt = Temporal.ZonedDateTime.from("2025-06-20T17:00+08[US/Eastern]")
    Uncaught RangeError: Offset +08:00 is invalid for 2025-06-20T17:00:00 in US/Eastern
        InterpretISODateTimeOffset ecmascript.mjs:1467
        ToTemporalZonedDateTime ecmascript.mjs:1531
        from zoneddatetime.mjs:478
        <anonymous> debugger eval code:1
    >> zdt = Temporal.ZonedDateTime.from("2025-06-20T17:00+08[US/Eastern]", {offset: 'ignore'})
    >> zdt.toString()
    "2025-06-20T17:00:00-04:00[US/Eastern]"

> So in cases 1 and 2, having a non-UTC date is not required

If the only operation you need is formatting, then I agree, you can apply the time zone to the instant right before it's displayed. But there are many other operations (such as arithmetic or computing durations between datetimes) you might want to do that do required a time zone. You might still be able to get away with only storing a UTC date, but it really depends on what you're doing.