Dear Jim, Martin, Chris et al. Thanks for this discussion and specially many thanks to Jim for spending the time to make a proposal. It was indeed an epic discussion on the email list, and it's great to see an outcome.
I agree with the proposal as Jim has made it, if I understand it correctly, except that I agree with Martin that the reference time in the time units should be given in the calendar specified by the calendar attribute. If we have calendar="julian", zero "days since 1917-10-25" means 7 Nov 1917 in the gregorian calendar (which is "proleptic" UTC). It does not mean 25 Oct 1917 in the gregorian calendar. In CF, as Chris says, a "calendar" is a way to translate from time-since-a-timestamp to another timestamp (timestamp being year, day, month, minute, second). The calendar attribute identifies the rules for converting between a time coordinate (with time units) and a timestamp (components of time). A crude way to picture these "rules" is that a calendar is defined by an ordered list of all the valid times. For the current set of CF calendars, it would be sufficient to list all the valid dates (YYYY-MM-DD) in the calendar, which have a spacing of 1 day (86400 s), but with the complication of leap seconds we have to regard the calendar as being defined by an ordered list of all the valid timestamps (YYYY-MM-DD HH:MM:SS) in the calendar, which have a spacing of 1 second. The reference time in the time-units is one of these timestamps. To work out the time coordinate for a given timestamp, you count how many valid timestamps there are between the reference and the one you want. Martin's interpretation of the reference time would modify Jim's proposal slightly, according to my understanding, which is as follows: gregorian_tai. The reference date in the time-units is TAI, not UTC. The calendar has all the Gregorian dates but no leap seconds. gregorian_utc. The reference date in the time-units is UTC. The calendar has all the Gregorian dates and includes leap seconds. gregorian. The reference date in the time-units is UTC, if it's real-world data. The calendar has all the Gregorian dates but no leap seconds, so the rules for converting between time coordinates and timestamps are the same as for gregorian_tai. The timestamps can be encoded and decoded successfully by these rules but the difference between two time coordinates which span a leap second will be incorrect. That is, the time coordinates are not "metric", in Jim's sense. As Jim has explained, most real-world data is probably like this, because the timestamp comes from a clock which is synchronised to UTC but it was converted to a time coordinate according to the no-leap-second rules. Moreover, there is a lot of climate model data which uses this calendar, and it's *correct* because there are no leap seconds in the model world. It's not really "UTC" but it's what the model uses. In the model world, the time coordinates are metric. I support introducing gregorian_tai and gregorian_utc for real-world applications which require time coordinates that take account of leap seconds. Should it be prohibited to use these two new calendars for dates before 1958-1-1, or are they gregorian before that date? I assume it should be prohibited to use gregorian_utc for dates in the future, since the leap seconds are unknown. Best wishes Jonathan -- 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-435227916
