7c72306a

Author: Tom Sydney Kerckhove <syd@cs-syd.eu>

Committer: Tom Sydney Kerckhove <NorfairKing@users.noreply.github.com>

ical-recurrence: ignore a generated leap second whatever DTSTART is

GREEN for the tests in the previous commit.

'localTimeExists' answered 'const True' for anything that was not a zoned
DATE-TIME, because the resolve/unresolve round trip it uses needs a time
zone.  A leap second needs no time zone to rule out, so it is now ruled
out in every branch, and BYSECOND=60 produces no instance whatever
DTSTART's value type is.

The predicate is a syntactic check on the local time:

    isLeapSecond = (>= 60) . Time.todSec . Time.localTimeOfDay

Honouring second 60 was never coherent.  Whether such a local time
survives resolving and unresolving depends on the time of day and on the
offset -- 23:59:60 at a zero offset survives, 00:59:60 does in a +01:00
zone, everything else normalises into the following minute -- so the
recurrence set came to depend on facts about neither the rule nor the
calendar.  The cost is that BYSECOND=60 never generates an instance, which
is the honest outcome: real leap seconds are announced for particular
dates and nothing here knows which.

'ICal.Recurrence.TimeZoneSpec' had its own copy of this predicate as a
let-binding, added when that property was revived.  It now uses the
exported one, so the concept has one definition.  That does not make the
property tautological: 'isLeapSecond' is a syntactic check, not something
derived from the round trip, and the three concrete cases in that file
still pin what actually happens to a leap second independently.

Timeline