Clarification of the handling of leap seconds #313

d70-t · 2021-03-01T13:55:28Z

Title

Clarification of the handling of leap seconds

Moderator

Requirement Summary

In order to correctly compute timestamps of measured variables where the reference date in the units attribute and the point in time of the measurement are separated by one or more added (or removed) leap seconds, it is required to know if leap seconds are to be counted or not.

Technical Proposal Summary

Add a sentence like the following to §4.4 Time coordinate:

Leap seconds are ignored during the calculation of all dates and times. That is, they are treated as if all clocks stand still during the presence of an added leap second or as if the clocks jump by one second across a removed leap second (if that should ever occur).

Benefits

Anyone who is working on high-frequency (sub-minute intervals) measurement data will benefit from this clarification. Without this change, time series wich cross an added (or removed) leap second can not be stored unambiguously using CF Conventions.

Furthermore, there there is considerable demand of specifying time in seconds since 1970-01-01 for historical reasons or other reference date far from the measured point in time. This specification is also not exact if the handling of leap seconds is not defined.

Errors due to different handling of leap seconds between data producers and data consumers lead to bugs which are hard to track and annoying. These errors can likely be reduced if handling of leap seconds is specified unambiguously.

Drawbacks

If leap seconds are ignored, measurements which happen exactly on the leap second can not be represented. This however is currently already the case in practice. In order to fix this additional issue, proper handling of leap seconds, TAI clocks and UTC clocks would have to be included. That topic is already being discussed in #148 and thus should not be part of this issue. Once #148 is settled (I hope that will be soon!), the added statement will not be true in general, but will be dependent on the specified calendar or other attributes and thus might need to be reworded slightly. I however don't think that this issue will affect the possibility to implement #148 in any negative way.

Status Quo

Leap seconds are not mentioned anywhere in CF Conventions. Usual libraries like cftime or numpy ignore leap seconds, but there's no specification that this library must be used and that what these libraries do is how it is intended to be. Thus for all implementations which I am currently aware of, nothing will change in practice, but discussions about how to implement custom solutions will become much simpler.

Associated pull request

#316

Detailed Proposal

(this is the same as above)

Add a sentence like the following to §4.4 Time coordinate:

Leap seconds are ignored during the calculation of all dates and times. That is, they are treated as if all clocks stand still during the presence of an added leap second or as if the clocks jump by one second across a removed leap second (if that should ever occur).

This issue is intentionally separate from #148. My hope is that this issue can be settled a lot quicker. I also think that these really are two different concerns as #148 would add additional, desirable functionality while this issue only removes ambiguity from the current specification. It is incomplete in the sense of the mentioned drawbacks in order to make the scope smaller and simpler to implement.

The text was updated successfully, but these errors were encountered:

JonathanGregory · 2021-03-01T20:59:00Z

Dear Tobias @d70-t

Thanks for raising this issue. I agree with your idea of clarifying the current convention as a separate issue from adding a convention for leap seconds. As you have no doubt seen, that other discussion #148 was very long and has stalled, because we didn't seem able to understand one another or reach a consensus. But perhaps we can return to it. If you have a definite requirement and use-case that will help.

You've labelled this ticket as a defect, and I agree that it arguably is simply an ambiguity or mistake, but in view of the history I don't think we should treat this as a defect issue. That would mean it would get accepted if no-one objected, whereas I think we should make sure there's some positive support, as required for an enhancement. Therefore I'll change the label. I hope that's OK with you.

You suggest that this issue applies to all existing calendars but actually I think it only affects the default/standard/gregorian calendar. The others are used only in models and definitely have no leap seconds. Do you think that's right?

It seems to me that the clearest way to describe this is as an issue affecting the computation of the interval of time between two instants of time each identified by components of date-time (year month day hour minute second). 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. As you say, we could simply state that this is the case.

It raises questions which logically I feel we should also make clear. However, in view of the previous discussion, I think they might be contentious.

Date-times between the end of the 60th second of the last minute of one day and the first second of the next day cannot be encoded as time coordinates. That's what you mean by "measurements which happen exactly on the leap second can not be represented", isn't it.
A date-time in that excluded range is not a correct decoding of a time coordinate in CF. For instance, 60 seconds after 23:59 should always be decoded as 00:00 on the next day.
A date-time in the excluded range should not be used as a reference time in a time unit e.g. we shouldn't allow "seconds since 2016-12-31 23:59:60" as units.

Best wishes

Jonathan

d70-t · 2021-03-02T17:32:09Z

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_gregorianand 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 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. 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

JonathanGregory · 2021-03-09T21:29:03Z

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 #148 may modify this set but would not be inconsistent with the above, I believe.

What do you think of that?

Best wishes

Jonathan

d70-t · 2021-03-10T14:48:40Z

Dear @JonathanGregory,

I think this is really good 👍

I especially like that this description has a strong focus on describing the mapping between the tuple of year, month, day, hour, minute, second and coordinate value as it is currently handled in practice. In my opinion, exactly this description is the most important missing part regarding the handling of leap seconds in the current CF Conventions and thus exactly to the point of this issue.

#148 may require a rewrite of the 60 second rule into calendar specific assumptions, but at this point, I am pretty sure that this can be done without contradicting the rule as written in your post (the simplest would be to just copy the paragraph into all existing calenders and replace it by other wordings for new calendars). However, I think this rewrite should not be done now.

I'd probably have a few more comments on the exact wording, but these are minor and I think it is easier to do it within a PR review than in an issue-message-stream. Do you agree?

All the best,
Tobi

JonathanGregory · 2021-03-10T15:20:02Z

Dear Tobi @d70-t

Our usual practice is to do as much discussion in the issue as possible. Once there is a PR, it's nonetheless still easier to follow the discussion if comments on it are made in the issue, as that means there's only one place to look. However, if you and I generally agree about the words, and since no-one else has yet expressed reservations, I think it would be fine to have a PR. Would you like to do that?

Best wishes

Jonathan

davidhassell · 2021-03-10T15:45:47Z

Hello @d70 and @JonathanGregory,

I have been hitherto silently following this, and also very much like Jonathan's suggested text (#313 (comment)). I think, in the absence of #148, it removes the current ambiguities and I would also welcome a PR.

Thanks,
David

taylor13 · 2021-03-10T16:23:21Z

Likewise, I have put off commenting, as the two of you have made good progress. Now that things are clearly getting serious, I would suggest to

Avoid any comment about "synchronization" with the civil calendar (which I think already is recognized in Clarification of the handling of leap seconds #313 (comment) as possibly leading to controversy). I think without leap seconds, it is impossible to fully synchronize the CF Gregorian calendar with our actual calendar; they may become out of sync by seconds.
Put off creating a term like 'leap second ignorant counting' until it might be needed.

I'll review the wording once the final proposal is in place, but I think most of the text suggested above is really quite good.

thanks to both of you for this contribution. Maybe I'll find time to think again about #148

chris-little · 2021-03-10T16:53:41Z

@davidhassell @JonathanGregory The proposed wording does seem to bring clarity to the CF text. However, I have a concern in that it seems to imply that ignoring leap seconds in UTC and the Gregorian calendar is acceptable. I recognise that it may have been, or still is, common practice. But UTC and the Gregorian calendar have leap seconds by definition.
Of course there are no leap seconds defined prior to 1972.

@JonathanGregory

This is the suggested initial wording from cf-convention#313 as authored by @JonathanGregory.

d70-t · 2021-03-10T17:39:15Z

I've prepared a PR at #316. It mostly contains @JonathanGregory's wording with two small changes identified by separate commits. Feel free to comment on the proposed wording.

I wasn't entirely sure about how to handle the remaining things of the release checklist, namely:

Authors updated in cf-conventions.adoc?
Next version in cf-conventions.adoc up to date? Versioning inspired by SemVer.
Conformance document up-to-date?

Can you provide me some assistance on how this should be done?

@taylor13 I agree with your suggestions and hope that the current PR is sufficient in not naming those things.

@chris-little I also fully agree that leap seconds should not be ignored, and indeed I have use cases where I really want to represent times within those leap seconds. However an even bigger problem is that I want to unambiguously specify at least most of the date-times. Currently there's obviously some way people handle the conversion of time values into date-times, but it is not written down, so datasets which might cross leap seconds are ambiguous.
I'll try to put effort in advancing a method of properly handling those missing leap seconds in the future, but I honestly think that that should be the second step and I like doing things step by step.

Regarding this issue, I only see two options to treat the importance of leap seconds:

add another note to the conventions that leap seconds are really important, but still can't be represented at the moment
don't do that and instead think more about forwarding Add calendars gregorian_tai and gregorian_utc #148 or the like

I strongly favor the second option.

And thank you all again for being so positive about this thing 🎉

Dave-Allured · 2021-03-10T19:04:44Z

@chris-little said:

But UTC and the Gregorian calendar have leap seconds by definition.

Be careful here. The real-world Gregorian calendar does not have leap seconds by definition.

In general world usage, "UTC" is a precise timekeeping system which includes leap seconds. "Gregorian" is a system of labeling calendar dates only, and has nothing to do with length of day, or leap seconds in particular.

In CF we use the calendar attribute "gregorian" in an extended sense, to identify a particular timekeeping system which combines both the real-world Gregorian calendar, and a fixed length day which does not use leap seconds.

I support the general premise of this issue, all currently defined CF calendars have fixed length days and do not include leap seconds. If this notion is generally accepted, then it will become easier to start adding some of the more precise timekeeping systems later.

sethmcg · 2021-03-10T19:17:41Z

I support this proposal and favor pushing forward on #148 rather than adding more about leap seconds here.

JonathanGregory · 2021-03-11T15:49:16Z

Dear Tobi @d70-t

Thanks for preparing the pull request.

I notice that you prefer the word "count", in "A time coordinate value is a number which represents a date-time as a count", "the counting unit" (meaning the unit of time in the units string), and "exactly 60 seconds to count" in each minute. I didn't use the word "count" because to me "count" specifically refers to integers (e.g. as in countable infinity versus uncountable infinity), so I find it misleading for floating-point numbers. I described a coordinate value as a "number" rather than a "count" because I understand "number" as possibly non-integral. However, quite possibly you find "number" misleading! I hope we can find some word that everyone likes for a number is not necessarily an integer. That's also why I wouldn't call it a "counting unit" - the coordinate value might be e.g. 3.142 days, but I don't think I'd say "We count 3.142 days".

My idea in drafting that text was that we can avoid the problem which @chris-little raises at this stage by being clear that the calendar is just concerned with the rules for calculating time coordinates from date-times and vice-versa. If we introduce UTC or other calendars with leap seconds we will have to introduce another distinction, but I hope we can agree this PR first. It sounds like you and others would also rather do that. In fact that was your original aim with this issue, I think.

Regarding your other questions

You should add yourself to the end of the list of additional authors.
The conformance document is in the same repository, and necessary changes should be included in the pull request, consistent with this change. Although this is not actually a change, we could add the requirement that the reference date-time in time units is not allowed to contain seconds equal to or greater than 60.
The next version will be 1.9. I expect it's already been changed by some other pull request.

Best wishes

Jonathan

d70-t · 2021-03-11T16:12:04Z

Dear @JonathanGregory,

yes, I also wasn't entirely happy with the word "count". I assumed that something like a fractional count would not be uncommon, but that might well be due to a lack in my understanding of the english language. I am happy with the term number as well.

It think the first instance of as a count can be removed. I just added it to create a reference from the unit in the units attribute to the number. We could probably change the wording of the units to ... units of the time coordinate variable (containing the unit of the number and the reference date-time).... I just want to avoid the unit of time as referring to time in this place feels a little bit like a cycle in reasoning.

Then for the last part we could maybe try something like ...it is assumed that the coordinate value advances by exactly 60 seconds from the start of any minute... or something similar in more proper english 😬. I'd like to point out that the 60 seconds are not about the actual time passed but about the amount of seconds the number has changed.

I'll have a look at the other points.

All the best,
Tobi

d70-t · 2021-03-11T16:45:57Z

Dear @JonathanGregory,

I've added me as an additional author and added the note on the 60th second to the conformance document.

Regarding the version, there are sill many occurrences of version 1.8 in the document as well as the conformance document. This is the reason why I didn't check the other items. I could update these, but it doesn't feel like all of these should be part of this PR.

Tobi

JonathanGregory · 2021-03-11T20:51:21Z

Dear Tobi @d70-t

OK, thanks. Those changes look fine to me.

I think the first instance of "as a count" can be removed.

Maybe we could just depend on the word "value", which has that meaning.

I just want to avoid the unit of time as referring to time in this place feels a little bit like a cycle in reasoning.

Yes, I sympathise.

I suggest rewriting the start in a different order:

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. A time coordinate value represents a date-time. In order to calculate a time coordinate value from a date-time, or the reverse, one must know the units attribute of the time coordinate variable (containing the time unit of the coordinate values and the reference date-time) and the calendar. The choice of calendar ...

Is that better?

it is assumed that the coordinate value advances by exactly 60 seconds from the start of any minute ... I'd like to point out that the 60 seconds are not about the actual time passed but about the amount of seconds the number has changed.

Yes, I see what you mean. Maybe, "it is assumed that the coordinate value increases by exactly 60 seconds from the start of any minute." That sounds more definitely a statement about the numerical value, I think.

I'm sure the version number will be updated when the next version is made.

Jonathan

d70-t · 2021-03-11T21:29:46Z

Dear @JonathanGregory,

I like your suggestions. I've included them into the PR and am also happy now with the current state of the PR.

All the best,
Tobi

JonathanGregory · 2021-03-12T07:58:01Z

Dear Tobi @d70-t

That looks fine to me. Since @davidhassell @taylor13 @Dave-Allured @sethmcg have also said they're in favour of it, we've got the required amount of support and no objections which haven't been addressed at present. If no-one raises any further concerns within three weeks from now, the proposal will be accepted.

Thanks and best wishes

Jonathan

JonathanGregory · 2021-03-31T13:03:06Z

To be consistent with the single occurrence in the existing version of the standard, and also with #315, we should write "date/time" in the new text introduced by this issue, instead of "date-time", which I wrote. I assert that this isn't a material change to the proposal, so we don't need to "reset the clock". This proposal will be accepted on Friday 2nd April if there are no further concerns expressed by then.

d70-t · 2021-03-31T13:19:45Z

Thanks @JonathanGregory. I agree that this is not a material change and I also don't have a particular preference for either variant. But as you say in #298, "date/time" is what has been in the conventions before. I've updated the PR accordingly.

JonathanGregory · 2021-03-31T14:39:19Z

Thanks for doing that, Tobi

JonathanGregory · 2021-04-03T09:00:37Z

I have merged #316. Thanks for initiating this proposal, Tobi @d70-t

d70-t · 2021-04-03T13:05:58Z

🎉

@d

* added example 6.1.2 to the list of examples; fixed cf-convention#284 * updated changes in history.adoc * removed fourth lines of third table in sect 9.3.1; fixed cf-convention#288 * updated history * Bring conformance doc in line with clarification to use of region names/area_types to allow use of flag_values and flag_meanings as per discussion in cf-convention#198 * Add support for variables of type string to conformance doc. See issue cf-conventions#139 * Revert "Bring conformance doc in line with clarification to use of region names/area_types to allow use of flag_values and flag_meanings as per discussion in cf-convention#198" This reverts commit f754457. * first draft of section 5.8 * format typo * rewording * rewording * rewording * New 'Do' Use value, and 'dimensions' entry * Domain construct * rewording * rewording * rewording * formatting of computed_standard_name entry * rewording * rewording * rewording * top-level * rewording * move fig 3 * rewording * span * rewording * data * rewording * rewording * rewording * conformance * recommended attributes * typo * dimensions * dimensions * format * typo * domain independence * domain optional * format * format * format * format * empty dimensions * long_name * UML * Update ch01.adoc * Update history.adoc * Add static assets to HTML check build * Add static assets to Travis upload job * Fix order of i/j in lon/lat bnds figure correct indices of neighbour cells in @d case * update/correct order of indices i/j in Fig 2 (2D lon/lat bounds) * update/correct order of indices i/j in caption of Fig 2 * rename "figure 1" to "figure 3" in Appendix i * correct indices of neighbour cells in @d case * update history Figures are generated from: https://github.com/neumannd/cell_bounds_figures_for_cf_conventions * updates arising from cf-convention#301 up to 2020-09-28 * correct label for 1.2 * format correction * reword empty dimensions example * comma * example links * long_name * formatting * missing 'construct' * term units * term units * standard names * typo * units conformance requirement * remove requirement for identical units * Copyedit * fixed typos * History * more text following 2020-11-27 discussions * bounds * tidy * tidy * tidy * tidy * reproducability * offset * indices * indices * indices * super * tie_point_dimension (1) * tie_point_dimension (2) * tie_point_dimension (3) * tie_point_dimension (4) * tie point * tie_point_dimension (5) * corrected interpolation_configuration description * zone/area rewording * zone/area rewording * multiple mappings * multiple mappings * multiple mappings * typos and some minor rewording suggestions * format * spell check * markup style * example formatting * example formatting * example formatting * example formatting * minor typesetting * interpolation_parameters * interpolation parameters variable dimensions * interpolation parameters variable dimensions * non-standard provision * interpolation parameters variable dimensions * captions, cdl * tidy * minumum size of interpolation zones * Appendix A attributes * interpolation -> sampling * Conformance - first draft * 2nd draft: better descriptions of allowed dimensions * typos * Correct 'is list' to 'is a list' * history cf-convention#304 * check on interpolation zone dimension size * Clarification of the handling of leap seconds This is the suggested initial wording from cf-convention#313 as authored by @JonathanGregory. * leap seconds: added the word "count" in some places The purpose of this change is to slightly highlight the difference between when seconds are used within the coordinate value for counting and the seconds which are part of the date-time. * leap seconds: minor wording extension * leap seconds: added reference to cf-convention#313 to history.adoc * add myself to the end of the list of additional authors * leap seconds: updated conformance text This change excludes values larger or equal to 60 for seconds in reference date-times in time unit attributes. Additionally, the reference time has been changed to reference date-time to agree with the wording in the proposed conventions text. * leap seconds: small rewording as discussed with @JonathanGregory Reasoning: counting may be associated with integral numbers, which is was not intended. We still like the idea of a little more separation between seconds as a unit of the value and seconds as in the date-times. * replace date-time with date/time * conformance changes for new interpolation variable * conformance changes for new interpolation variable * conformance changes for new interpolation variable * conformance changes for new interpolation variable * appendix A changes for new interpolation variable * appendix A changes for new interpolation variable * lat lon tie point definition * spelling * URI -> URL * lower resolution -> sampled * Use on domain variable * typo * Move 'interpolation dimension' definition to first occurence * Minor re-wording * Fix cross-reference * Re-wording * typesetting * tie point index re-wording * Rotation of interpolation axes for two dimensional methods and mino corrections * terminology: interpolation variable and tie point variable * typo * examples in toc * Replace expression for gsqr with equivalent, but numerically more accurate version * Update authors * Update history * Rename attribute tie_points to coordinate_interpolation (Change 2) * Reword section Interpolation and Non-Interpolation Dimensions (Cahnge 10) * Rename tie_point_dimensions attribute to tie_point_mapping (Change 2) * Change term 'tie point variable' to 'tie point coordinate variable' (Change 4) * Reword first paragraph of Section 8 (Change 6) * Remove sentence "This form of compression may also be..." (Change 7) * Update sentence: "A single interpolation dimension may be associated..." (Change 9) * Reword section "Interpolation and non-interpolation dimension" (Change 10) * Improve sentence "An interpolation zone must span at least two points..." (Change 11) * Correct sentence "....must be a subset of zero or more of the ..." (Change 12) * Reword text about the dimensions of interpolation parameter (Change 13) * Improve sentence "The bounds of a tie point must be the same..." (Change 14) * Reduce number of data variables in Example 8.5 (Change 16) * Rename "terms to continuous area" and "interpolation subarea" (Change 5) * Improve wording of "An interpolation subarea must span..." (Change 11) * Remove paragraph "The same interpolation variable may be multiply mapped ...." no longer relevant * Rename terms to: subsampled dimension, interpolated dimension and non-interpolated dimension * Combine the tie_point_dimensions and tie_point_indices attributes (Change 1) * Update figures to match new terms * Improve description of non-overlapping interpolation subareas * Improve description of non-overlapping interpolation subareas * Update Example 8.6 to correctly specify one dimension interpolation for X and Y * Improve wording of Tie Point Index Mapping (Change 8) * Clarify interpolation subarea size * Clarify dimensions in Figure 2 * Add new section 8.3.9, "Computational Precision" * Combine the tie_point_dimensions and tie_point_indices attributes (Change 1) * Remove paragraph "A single interpolated dimension may be associated with multiple ...." no longer relevant * Update ch08.adoc Co-authored-by: David Hassell <[email protected]> * Update ch08.adoc Co-authored-by: David Hassell <[email protected]> * Update ch08.adoc Co-authored-by: David Hassell <[email protected]> * Update ch08.adoc Co-authored-by: David Hassell <[email protected]> * Change sampl... to subsampl... * Rewrite section Interpolation of Cell Boundaries (Change 15) * Constrain interpolation parameters to support bounds interpolation * Update <<link>> names and figure names to new terms * Require tie points to be numeric type and have no missing values * Update Appendix J with new terms and names * Correct spelling mistake in Appendix J * Correct numbering mistake in Appendix J * Change "iz" (interpolation zone) to "is" (interpolation subarea) in App J (Change 3) * Correct "target dimension" to "interpolated dimension" (Change 17) * Introduce section numbering and remove table captions in Appendix J * Include interpolation argument s in figure 1 and 2 * Move Figure 1 and 2 in Appendix J futher down * State tht for linear interpolation, the coordinates of the interpolated points are evenly spaced. * Change "equivalently" to "similarly" in explanation of s1 and s2 in App J * Rename cofficeint "c" to "w" in Appendix J to avoid confusion with point C * Move "Common Conversions and Formulas" in front of "Interpolation Methods" in Appendix J * Add "s" to "each of the interpolated dimension" in Appendix J * Minor wording improvements arising from review * Conformance for bounds tie points * computational_precision conformance Co-authored-by: Daniel Neumann <[email protected]> Co-authored-by: Rosalyn Hatcher <[email protected]> Co-authored-by: JonathanGregory <[email protected]> Co-authored-by: Daniel Lee <[email protected]> Co-authored-by: Daniel Lee <[email protected]> Co-authored-by: David Blodgett <[email protected]> Co-authored-by: AndersMS <[email protected]> Co-authored-by: Tobias Kölling <[email protected]> Co-authored-by: Tobias Kölling <[email protected]>

d70-t added the defect Conventions text meaning not as intended, misleading, unclear, has typos, format or language errors label Mar 1, 2021

d70-t mentioned this issue Mar 1, 2021

Handling of leap seconds zarr-developers/zarr-specs#110

Open

JonathanGregory added enhancement Proposals to add new capabilities, improve existing ones in the conventions, improve style or format and removed defect Conventions text meaning not as intended, misleading, unclear, has typos, format or language errors labels Mar 1, 2021

d70-t pushed a commit to d70-t/cf-conventions that referenced this issue Mar 10, 2021

Clarification of the handling of leap seconds

2878db1

This is the suggested initial wording from cf-convention#313 as authored by @JonathanGregory.

d70-t added a commit to d70-t/cf-conventions that referenced this issue Mar 10, 2021

leap seconds: added reference to cf-convention#313 to history.adoc

94932d6

d70-t mentioned this issue Mar 10, 2021

Leap seconds clarification #316

Merged

4 tasks

JonathanGregory closed this as completed Apr 3, 2021

JonathanGregory mentioned this issue Jun 21, 2021

Interpretation of negative years in the units attribute #298

Closed

JonathanGregory mentioned this issue Sep 6, 2022

Add calendars gregorian_tai and gregorian_utc #148

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Clarification of the handling of leap seconds #313

Clarification of the handling of leap seconds #313

d70-t commented Mar 1, 2021 •

edited by JonathanGregory

Loading

JonathanGregory commented Mar 1, 2021

d70-t commented Mar 2, 2021 •

edited

Loading

JonathanGregory commented Mar 9, 2021

d70-t commented Mar 10, 2021

JonathanGregory commented Mar 10, 2021

davidhassell commented Mar 10, 2021

taylor13 commented Mar 10, 2021

chris-little commented Mar 10, 2021

d70-t commented Mar 10, 2021 •

edited

Loading

Dave-Allured commented Mar 10, 2021

sethmcg commented Mar 10, 2021

JonathanGregory commented Mar 11, 2021

d70-t commented Mar 11, 2021

d70-t commented Mar 11, 2021

JonathanGregory commented Mar 11, 2021

d70-t commented Mar 11, 2021

JonathanGregory commented Mar 12, 2021

JonathanGregory commented Mar 31, 2021

d70-t commented Mar 31, 2021

JonathanGregory commented Mar 31, 2021 via email

JonathanGregory commented Apr 3, 2021

d70-t commented Apr 3, 2021

Clarification of the handling of leap seconds #313

Clarification of the handling of leap seconds #313

Comments

d70-t commented Mar 1, 2021 • edited by JonathanGregory Loading

Title

Moderator

Requirement Summary

Technical Proposal Summary

Benefits

Drawbacks

Status Quo

Associated pull request

Detailed Proposal

JonathanGregory commented Mar 1, 2021

d70-t commented Mar 2, 2021 • edited Loading

JonathanGregory commented Mar 9, 2021

d70-t commented Mar 10, 2021

JonathanGregory commented Mar 10, 2021

davidhassell commented Mar 10, 2021

taylor13 commented Mar 10, 2021

chris-little commented Mar 10, 2021

d70-t commented Mar 10, 2021 • edited Loading

Dave-Allured commented Mar 10, 2021

sethmcg commented Mar 10, 2021

JonathanGregory commented Mar 11, 2021

d70-t commented Mar 11, 2021

d70-t commented Mar 11, 2021

JonathanGregory commented Mar 11, 2021

d70-t commented Mar 11, 2021

JonathanGregory commented Mar 12, 2021

JonathanGregory commented Mar 31, 2021

d70-t commented Mar 31, 2021

JonathanGregory commented Mar 31, 2021 via email

JonathanGregory commented Apr 3, 2021

d70-t commented Apr 3, 2021

d70-t commented Mar 1, 2021 •

edited by JonathanGregory

Loading

d70-t commented Mar 2, 2021 •

edited

Loading

d70-t commented Mar 10, 2021 •

edited

Loading