> It’s not like programming languages support representing 61-second minutes anyway
This is not true. Someone already noted that Raku supports leap seconds. I think this may be partly my fault, because Perl 5's most popular datetime library, `DateTime.pm`, supports leap seconds.
It's my fault because I created `DateTime.pm` and implemented its leap seconds support. In retrospect, this was almost certainly a mistake. Almost no one cares about leap seconds. It just produces all sorts of weird confusion. Like why does adding 60 seconds produce a different result than adding 1 minute, but only rarely?
And it makes the code _way_ more complicated, especially since I wanted to validate whether setting second to 60 was valid.
This seems simple. Why not just look up the leap second table and check? Well, the `DateTime` constructor takes time components (including `second => 60`) and _any_ time zone. So we have to convert the date/time passed to the constructor to UTC in order to do that lookup. But doing that conversion ... ended up involving values that include leap seconds because of historical reasons.
It's a huge mess for very little gain.
As to Raku, I think it's stdlib datetime library borrowed from Perl 5's `DateTime.pm` quite heavily so it inherits some of the same bad design decisions.
I like that you did it and can look back with a more elegant solution.
What was the thought process originally? Were you just too focused on the problem?
I find that if I'm too close to the problem and too focused for [arbitrary timeframe], this is the type of thing that happens. The joy of fixing something before it's broken takes over.
I wrote this code in the early 2000s, so I don't remember the exact thought process. But I think my thinking was something along the lines of "this is a thing that exists, therefore I should model it 100% accurately". But I think the right way to think about it is "this is a thing that exists but most developers would be better off never thinking about, therefore I should omit it entirely".
Of course, the _real_ correct solution is to split up a date/time library into a number of closely related classes/structs, and allow users to pick the one that meets their needs. So most folks would pick the leap second-free class, but a few would use the one with leap seconds baked in.
This is not true. Someone already noted that Raku supports leap seconds. I think this may be partly my fault, because Perl 5's most popular datetime library, `DateTime.pm`, supports leap seconds.
It's my fault because I created `DateTime.pm` and implemented its leap seconds support. In retrospect, this was almost certainly a mistake. Almost no one cares about leap seconds. It just produces all sorts of weird confusion. Like why does adding 60 seconds produce a different result than adding 1 minute, but only rarely?
And it makes the code _way_ more complicated, especially since I wanted to validate whether setting second to 60 was valid.
This seems simple. Why not just look up the leap second table and check? Well, the `DateTime` constructor takes time components (including `second => 60`) and _any_ time zone. So we have to convert the date/time passed to the constructor to UTC in order to do that lookup. But doing that conversion ... ended up involving values that include leap seconds because of historical reasons.
It's a huge mess for very little gain.
As to Raku, I think it's stdlib datetime library borrowed from Perl 5's `DateTime.pm` quite heavily so it inherits some of the same bad design decisions.