Hacker News new | ask | show | jobs
by ariebovenberg 858 days ago
Author of the blog post here—

1) You're absolutely right, I'll fix this mistake in the example.

2) "Made up" was perhaps stirring the pot too much ;), but the fact remains that a timestamp is created when one essentially doesn't exist. That this is meticulously documented in PEP495 doesn't change this fact.

Note that PEP495 also explicitly describes some of the other pitfalls. Documenting a 'suprise' is not the same as eliminating it.

> Finally if we disallow creating non-existent datetimes in the proposed library, how do we represent the 2am in "clock changes forwards at 2am"? Use 3am? There are tradeoffs.

Indeed, there are always tradeoffs. Often, only time can tell what was the 'least bad' decision. It is telling though that modern datetime libraries (Noda Time, Chrono, Temporal) in other languages choose to not represent these 'missing' local times.

4 comments

I must add that I do appreciate you challenging the status quo. Excited to see where your library leads.

> modern datetime libraries … in other languages choose to not represent these 'missing' local times.

Another edge case with throwing errors over gap times is eventually a region’s dst policies may change. So what used to be valid can now be invalid (and vice versa). Updating the library must be done with an audit of existing data, or suffer loud unexpected failures.

Thanks for taking the time to address this critic. Easier to be a critic than a creator after all.

Indeed, structural changes to timezones also need to be handled. Temporal has a good approach here https://tc39.es/proposal-temporal/docs/ambiguity.html#ambigu....

Basically:

- Store the offset and the tz ID

- When deserializing, allow explicit choice what to do: keep the offset (i.e. same moment in time) or keep the local time (i.e. same time on the 'wall clock')

> Documenting a 'surprise' is not the same as eliminating it.

I'm going to have to remember that one

> Documenting a 'suprise' is not the same as eliminating it

I'd go as far as saying documenting a surprise is basically having a bug and writing "won't fix".

> only time can tell

I see what you did there.