1852Re: [ISO8601] Re: Wow, no posts for a long time
- Sep 21 8:55 AMOn 2006-09-18, piebaldconsult wrote:
> > [d] A Note to the definition of "duration" says that leap secondsYou are perfectly right, I stand corrected. I should not have put
> > must be "accounted" for in the length of epoch intervals.
> Which section of which version? I don't see that verbiage.
the word, "accounted", within quotes.
> Section 2.1.6 in version :2004 hasOf course you can. The question is whether it can be done while
> NOTE 1 In the case of discontinuities in the time scale, such as a leap
> second or the change from winter time to summer time and back, the
> computation of the duration requires the subtraction or addition of the
> change of duration of the discontinuity.
> Although that seems pretty clearly to support your question, I could
> still argue that it doesn't, that it's not clear, and that I can twist
> it to my own devious ends.
still conforming with ISO 8601:2004. There are two reasons in favor:
First, this is just a Note, and as such it does not constitute a
normative requirement of ISO 8601.
Second, there is a (normative) sentence [1 p12]:
This International Standard does not assign any particular
meaning or interpretation to any data element that uses
representations in accordance with this International
Standard. Such meaning will be determined by the context of
Nevertheless, the standard must assign _some_ meaning to its notations,
and so it does. It states (again in a Note in [2.2.2]) that
2005-12-31T23:59:60Z is one second before 2005-12-31T24:00:00Z.
The standard seems to require that the duration of the time interval
is PT02S, I have to assume.
> Given 23:55:00 and adding PT10M for most nights will result inFor UTC timestamps, I think that's what the standard says, yes.
> 00:05:00, but on a leap-second night we have to consider the
> possibility that the result is 00:04:59, yes?
Other timescales, such as UT or TAI or GPS time or TCG do not
have leap seconds, only UTC and its translates (zone times) do.
> I, for one, don't want that result, so I'll add the "duration of theNor do I want that result with UTC in most, if not all, cases. I am
> discontinuity" of the leap second as required, yielding the value I
> _do_ want (00:05:00) even though there may be some who'd argue that
> that's wrong. I can certainly see their point, but I'm still going to
> do whatever a darn well please, it won't matter in most applications.
just not sure whether this would still conform with ISO 8601:2004.
- << Previous post in topic Next post in topic >>