Hi @ChrisBarker-NOAA : thanks ... but my question was slightly different. Suppose, for instance, that the data records the frequency of some event (e.g. `frequency_of_lightning_flashes_per_unit_area` which has units of `m-2 s-1`) and the user wants to know the number of events in the elapsed time interval. Taking the two times as `0` and `2 minutes since 2016-12-31 23:59:00`, your answers imply that the correct approach is to convert the time to UTC time-stamps to compute the elapsed time of 121 seconds and use that in his calculation rather than using the numerical time coordinate directly.
This is rather unwieldy, and likely to be ignored. It would also mean, if the user went through the process, he would get a different answer from that obtained by the data provider who has declared his intention to ignore leap seconds. As you suggest, this calendar would have to be restricted specifically for time values computed directly from the UTC time stamps. Someone who is taking measurements at fixed intervals from a starting point, and would need to use a different calendar. There also appears to be an assumption that the user is storing raw observations, as any calculation the user does which involves time is likely to be affected by the neglect of the leap second. Do you think the idea is to have the use of this calendar restricted in this way? To me, this looks as though it would be better encoded with a new standard name, e.g. `time_stamp`, which should make it clearer to users that a direct delta of the variable values is not the same as a time delta. -- 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-437272623
