Dear Tobi @d70-t I haven't found any evidence on the web of the Julian calendar using leap seconds, but for the sake of simplicity I agree with your original proposal that for the moment we can make a general statement, rather than calendar-specific ones. It can be revised again if leap-second-aware calendars are included.
Like you, I'm nervous of your subtle point about civil time, because it feels like it might be treading on the toes of one of the controversies which prevented us from agreeing about the leap seconds before. However, I'm willing for us to try again! In my opinion, we should be able to avoid problems by clarifying the purpose of calendars _as things stand_ in CF as solely for encoding and decoding date-times. They say nothing about what these date-times mean or might be used for. We would have to revise this interpretation if leap-second-aware calendars are introduced. This is one of the things which caused problems before, if I remember correctly. Section 4.4 on "Time coordinate" starts by defining `units` of time and the reference date-time string. That is all fine in any calendar. Section 4.4.1 on "Calendar" begins as follows: > In order to calculate a new date and time given a base date, base time and a > time increment one must know what calendar to use. For this purpose we > recommend that the calendar be specified by the attribute `calendar` which is > assigned to the time coordinate variable. I suggest that we elaborate this paragraph, for instance: > A time coordinate value is a number which represents a date-time. A date-time > is the set of numbers which together identify an instant of time, namely its > year, month, day, hour, minute and second, where the second may have a > fraction but the others are all integer. In order to calculate a time > coordinate value from a date-time, or the reverse, one must know the `units` > of the time coordinate variable (containing the unit of time and the > reference date-time) and the calendar. The choice of calendar defines the set > of dates (year-month-day combinations) which are permitted, and therefore it > specifies the number of days between the times of `0:0:0` (midnight) on any > two dates. > When a time coordinate value is calculated from a date-time, or the reverse, > it is assumed that there is an interval of exactly 60 seconds from the start > of any minute (identified by year, month, day, hour, minute, all being > integers) to the start of the next minute, with no leap seconds, in all CF > calendars. This assumption has various consequences when real-world > date-times from calendars which do contain leap seconds (such as UTC) are > stored in time coordinate variables: > * Any date-times between the end of the 60th second of the last minute of one > hour and the start of the first second of the next hour cannot be represented > by time coordinates e.g. `2016-12-31 23:59:60.5`. > * A time coordinate value must not be interpreted as representing a date-time > in the excluded range. For instance, `60 seconds after 23:59` means `00:00` > on the next day. > * A date-time in the excluded range must not be used as a reference date-time > e.g. `seconds since 2016-12-31 23:59:60` is not a permitted value for `units`. > * It is important to realise that a time coordinate value does not > necessarily exactly equal the actual length of the interval of time between > the reference date-time and the date-time it represents. > It is recommended that the calendar be specified by the `calendar` attribute > of the time coordinate variable. After that, we describe the values it can currently have. Issue https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/148__;!!G2kpM7uM-TzIFchu!gNLHoHI3kqFZiUW6ZeMMgIJb6yb3BWQHzrd9OpmINsiy0zmra0OZuJdE3s1xsT1mv0CTMr--0cg$ may modify this set but would not be inconsistent with the above, I believe. What do you think of that? Best wishes Jonathan -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/313*issuecomment-794478943__;Iw!!G2kpM7uM-TzIFchu!gNLHoHI3kqFZiUW6ZeMMgIJb6yb3BWQHzrd9OpmINsiy0zmra0OZuJdE3s1xsT1mv0CTrVgF4u0$ 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].
