Dear @JonathanGregory, thank you for this motivating reply! I am also fine with handling this as an enhancement. This will add some more pressure towards a good formulation, but that shouldn't be a bad thing 😄 I also have a use case for a new version of CF-Conventions which are able to handle leap seconds, but I want to get this one fixed first.
--- My Idea was to keep it general, such that the sentence covers all the cases. I.e. if a calendar does not know about leap seconds anyways, it does not matter if the "ignore leap seconds" rule is applied or not. We could * [ ] go one step further and include special wordings for all of the calendars, in anticipation of new calendars which handle things differently or * [ ] we could postpone calendar-specific wording to the point in time when it will become relevant. If we do calendar-specific wording, we should still ensure that no ambiguity regarding leap seconds may occur for the others. That is, * we need something like **"ignore leap seconds in counting time deltas"** (i.e. the sentence from above) for default, `standard`, `gregorian`, `proleptic_gregorian`and most likely also `julian` (I don't know much about the Julian calendar, but Wikipedia says "For any given event during the years from 1901 to 2099 inclusive, its date according to the Julian calendar is 13 days behind its corresponding Gregorian date.", thus it would make a lot of sense if the same rules which apply to `gregorian` apply to `julian` as well. * For `noleap`, `365_day`, `all_leap`, `366_day` and `360_day` we should state something like **"there are no leap seconds"**, if there really are no leap seconds. * `none` might be the only calendar which does not need any wording about leap seconds. --- Regarding the second part of your post on describing this as an issue of the computation of time-deltas. I agree with all what you have written. I would probably rephrase one sentence a little: > When this calculation is done, it is assumed in CF calendars that 00:00 on > any calendar day is 60 seconds after 23:59 on the previous calendar day. into > When this calculation is done, it is assumed in CF calendars ( or in this > calendar? ) that every increment of one minute occurs exactly after a > difference of 60 counted seconds (e.g. 00:00 on any calendar day is 60 > seconds after 23:59 on the previous calendar day). This will also cover the case in which the leap second is not inserted at midnight of the calendar (i.e. when using time-zone aware reference times). There's just one more subtlety which might or might not be worth noting (and I have great fear while writing it as I really hope that it does not trigger a long discussion): * The component-wise date time (year month day hour minute second) is synchronized with the underlying civil calendar (i.e. Gregorian, Julian etc...) This might be clear to everyone, but the thing is that in principle there would be another solution to the constraints you mentioned which would be to continue counting the component-wise date time which then would get out of sync with the "real" calendar. (This is what [`std::tai_clock`](https://en.cppreference.com/w/cpp/chrono/tai_clock) does in the recent C++ standard library, but we do not want in this issue). --- I am currently thinking of creating a term like `leap second ignorant counting`, which could be added to [§4.4](http://cfconventions.org/cf-conventions/cf-conventions.html#time-coordinate). There would be a new small paragraph, describing how leap second ignorant counting works (basically what you've written above) and then each currently existing calendar (except `none`) will either refer to `leap second ignorant counting` or state that "there are no leap seconds". If you like, I could draft a PR which could be used as a base to talk about the wording. All the best, Tobi -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/313#issuecomment-789080229 This list forwards relevant notifications from Github. It is distinct from [email protected], although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to [email protected].
