~b @torresjrjr@qoto.org

@acousticmirror @rml
tyvm! Looks just like what I wanted.

@captainepoch

> [...] an important announcement: I will migrate all my repositories and projects from Sourcehut to Codeberg in the following days (including Husky). Over the last year I tried to make myself comfortable with the email workflow, but over time, I felt that workflow is not suitable for me.

Awh... All that contributor frustration! I understand you just want Husky development to progress.

@captainepoch
There's *a lot* to unpack and explain, but basically,

This thread on leap minutes and hours got me thinking
https://pairlist6.pair.net/pipermail/leapsecs/2022-November/thread.html

And this post made me think and disagree
https://pairlist6.pair.net/pipermail/leapsecs/2022-November/007444.html

Resolving ambiguous or nonexistent UTC timestamps is a much easier and encapsulable problem when the shifts and deltas are within 1 second. The domain of applications which handle UTC leapsecs are niche (scientific, military, fintech), and when they do, it's fairly simple, or can be with good design.

The @hare standard library separates the concerns of 'civil' timeshifts (timezones, DST) and timescale timeshifts (leap seconds), going as far as to include a 'timescale' type.

https://docs.harelang.org/time/chrono#timescale

The proposed alternative leap-minutes or leap-hours make a lot civil time software needlessly complicated, blurring 'civil' and 'timescale'. The same clusterduck of problems with timezone shifts and DST would now be part of UTC itself.

Then there's also the Earth's phase and velocity of rotation, drifting noons and midnights, politicians and dictators chiming in, forward compatibility, etc. It's a charged topic for sure.