hi @JimBiardCics .. my previous comment (2 above) was a response to your post 4 above, before I saw your comment addressed to me (3 above) ...
Firstly, in response to your most recent question: If you add 120 seconds to `2016-12-31T23:59:00Z (UTC)` you get `2017-01-01T00:00:59Z (UTC)` because of the leap second. You appear to be suggesting that `2017-01-01T00:00:59Z` could be encoded with `119 unit_formerly_known_as_seconds since 2016-12-31T23:59:00Z` in the case of the calendar formerly known as `gregorian_utc`. The `unit_formerly_known_as_seconds` is not the same as SI seconds. `120 seconds` has a unique meaning for all other calendars which is not modified in any way by the choice of calendar. A system in which two physical seconds map onto one unit of measure is introducing substantial new complexity. I didn't realise that you has previously considered the introducing a TAI-timestamped calendar. I don't understand your conclusion that this would require 3 new calendars. To be, it appears that we would want two versions of `gregorian`, one with leap seconds (i.e. UTC) and the other without (fixed minutes, as used for TAI). Can't we get away with one new calendar, and a clarification of the definition of `gregorian`? If I've understood correctly (sorry if I've been a bit slow) you are concerned about users who have a sequence of UTC time stamps such as: - 2016-12-31T23:59:40Z - 2016-12-31T23:59:50Z - 2016-12-31T23:59:60Z - 2017-01-01T00:00:10Z and would like to encode them as times in `seconds since 2016-12-31T23:59:40Z`. The correct answer would be [0,10,20,31]. If their software is not leap-second aware they might get [0,10,20,30], but they could also get [0,10,0,30] (60 seconds identified as 0) or [10,10,NaN,30] (software fails silently on seeing 60 seconds). Rather than create a kludgy fix in the standard, couldn't we provide people with clearer guidance? The leap seconds are not that complicated .... though it took be a while to get the information and it be useful to make that bit easier for our users, e.g. the authorise IETF list of leap seconds is [here](https://www.ietf.org/timezones/data/leap-seconds.list) .. and this list will be updated at least 6 months before a new leap seconds is introduced. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/148#issuecomment-435109348
