--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I have merged
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/316__;!!G2kpM7uM-TzIFchu!h4EXG1rzDivakhNumhXyj6qiUNiDyd3WDAZO82RBAR9SbJFfIxEYTqkgSCSx2ZNZBTX5O8ncm7U$
. Thanks for initiating this proposal, Tobi @d70-t
--
You are receiving this because you are
Closed #313.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thanks for doing that, Tobi
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
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.
--
You are receiving this because you are
To be consistent with the single occurrence in the existing version of the
standard, and also with
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/315__;!!G2kpM7uM-TzIFchu!gO-5lKhil7wVgczejO67eGxrYCWdyXMMvny5O7WJF_hEH4xbCRE_AT4F-vLg3vDGpnBK-cZtxrY$
, we should
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
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
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
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
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
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
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
I support this proposal and favor pushing forward on #148 rather than adding
more about leap seconds here.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@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"
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
@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
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
1. Avoid any comment about "synchronization" with the civil calendar (which I
think already is recognized in
Hello @d70 and @JonathanGregory,
I have been hitherto silently following this, and also very much like
Jonathan's suggested text
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
Dear @JonathanGregory,
I think this is really good :+1:
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
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
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
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
https://github.com/cf-convention/cf-conventions/issues/148 was very long
# 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
24 matches
Mail list logo
