Loading ...
Sorry, an error occurred while loading the content.

Wow, no posts for a long time

Expand Messages
  • piebaldconsult
    Do the recent new members have no questions? Did the past posts and files answer the questions?
    Message 1 of 12 , Sep 6, 2006
    View Source
    • 0 Attachment
      Do the recent new members have no questions?

      Did the past posts and files answer the questions?
    • Michael Deckers
      ... Sure we do. Here are some of mine on [ISO 8601:2004]: [a] In the notation of a time interval by its start and end, is there any requirement that the end
      Message 2 of 12 , Sep 7, 2006
      View Source
      • 0 Attachment
        On 2006-09-06, piebaldconsult wrote:

        > Do the recent new members have no questions?

        Sure we do. Here are some of mine on [ISO 8601:2004]:

        [a] In the notation of a time interval by its start and end,
        is there any requirement that the end shall not be
        before the start? Can a time interval be empty?

        [b] While [ISO 8601:2004] has removed the concept of "truncated"
        notations, they still seem to allow the omission of "higher
        order time elements" in the notation of the end point of a
        time interval given by its start and end. There is no syntax
        for such omissions, so it is not clear what can be omitted,
        and which separators must be written. Which of the following
        are allowed:
        2006-09-07/08
        2006-09-07/-08
        2006-09-07/07-09-07 -- is century a "time element"?
        2006-09-07/T12 -- for 2006-09-07/2006-09-07T12
        2006-w36-4/-251 -- for 2006-w36-4/2006-251
        2006-w36-4/251 -- for 2006-w36-4/2006-251

        [c] By "mutual agreement", a duration can be given as eg
        P0001-02-03
        to indicate "1 year + 2 months + 3 days". This would allow
        P-0001-02-03
        but what does it mean? "durations" must not be negative
        in [ISO 8601:2004].

        [d] A Note to the definition of "duration" says that leap seconds
        must be "accounted" for in the length of epoch intervals.
        Even though Notes are not normative, does this mean that
        the end point of
        2005-12-31T12Z/P1D
        shall be 2006-01-01T11:59:59Z rather than 2006-01-01T12:00:00Z.
        (A leap second occured at 2005-12-31T23:59:60Z.)

        Michael Deckers
      • piebaldconsult
        ... No, none that I can see. ... No, in :2004 it s section 4.4.4.1 which is the same as :2000 section 5.5.4.1 ... combining any two complete date and time of
        Message 3 of 12 , Sep 14, 2006
        View Source
        • 0 Attachment
          > [a] In the notation of a time interval by its start and end,
          > is there any requirement that the end shall not be
          > before the start?

          No, none that I can see.

          >Can a time interval be empty?

          No, in :2004 it's section 4.4.4.1 which is the same as :2000 section
          5.5.4.1

          "... combining any two complete date and time of day
          representations ..."

          > [b] While [ISO 8601:2004] has removed the concept of "truncated"
          > notations, they still seem to allow the omission of "higher
          > order time elements" in the notation of the end point of a
          > time interval given by its start and end. There is no syntax
          > for such omissions, so it is not clear what can be omitted,
          > and which separators must be written. Which of the following
          > are allowed:
          > 2006-09-07/08
          > 2006-09-07/-08
          > 2006-09-07/07-09-07 -- is century a "time element"?
          > 2006-09-07/T12 -- for 2006-09-07/2006-09-07T12
          > 2006-w36-4/-251 -- for 2006-w36-4/2006-251
          > 2006-w36-4/251 -- for 2006-w36-4/2006-251

          These are in :2004 section 4.4.5 which is the same as :2005 5.5.5

          And "Mutual agreement" is required here. However, I would not use any
          of the "incomplete" representations. They seem to me to be more
          useful to human-readability and less useful to computer-
          understandability. The computer doesn't mind reading and writing a
          few more bytes.

          > [c] By "mutual agreement", a duration can be given as eg
          > P0001-02-03
          > to indicate "1 year + 2 months + 3 days". This would allow
          > P-0001-02-03
          > but what does it mean? "durations" must not be negative
          > in [ISO 8601:2004].

          Hmmm... no, the standard says "PYYYY ..." , not "P+-YYYY ..."

          > [d] A Note to the definition of "duration" says that leap seconds
          > must be "accounted" for in the length of epoch intervals.
          > Even though Notes are not normative, does this mean that
          > the end point of
          > 2005-12-31T12Z/P1D
          > shall be 2006-01-01T11:59:59Z rather than 2006-01-
          01T12:00:00Z.
          > (A leap second occured at 2005-12-31T23:59:60Z.)

          Unclear in :2000, :2004 is better, section 2.2.7 says

          "
          2.2.7
          day
          <duration> duration of a calender day

          NOTE The term "day" applies also to the duration of any time interval
          which starts at a certain time of day at a certain calendar day and
          ends at the same time of day at the next calendar day.
          "

          So I wouldn't worry about them.
        • Michael Deckers
          Thanks for your extensive reply! ... I do not see what you mean. The referenced text is: [4.4.4.1] Representations of time intervals identified by start and
          Message 4 of 12 , Sep 15, 2006
          View Source
          • 0 Attachment
            Thanks for your extensive reply!
            On 2006-09-14, piebaldconsult answered my questions:

            > > Can a time interval be empty?

            > No, in :2004 it's section 4.4.4.1 which is the same
            > as :2000 section 5.5.4.1.
            > "... combining any two complete date and time of day
            > representations ..."

            I do not see what you mean. The referenced text is:
            [4.4.4.1]
            Representations of time intervals identified by start and end
            When the application identifies the need for a complete
            representation of a time interval, identified by its start
            and its end, it shall use an expression in accordance with
            4.4.2 combining any two complete date and time of day
            representations as defined in 4.3.2, provided that the
            resulting expression is either consistently in basic format
            or consistently in extended format.
            How does that imply that the interval is not empty? An empty
            interval could be specified in at least two ways:
            -- start point (at or) after the end point
            -- duration equal to 0 s (for a non-closed interval)

            > > [b] While [ISO 8601:2004] has removed the concept of "truncated"
            > > notations, they still seem to allow the omission of "higher
            > > order time elements" in the notation of the end point of a
            > > time interval given by its start and end. There is no syntax
            > > for such omissions, so it is not clear what can be omitted,
            > > and which separators must be written. Which of the following
            > > are allowed:
            > > 2006-09-07/08
            > > 2006-09-07/-08
            > > 2006-09-07/07-09-07 -- is century a "time element"?
            > > 2006-09-07/T12 -- for 2006-09-07/2006-09-07T12
            > > 2006-w36-4/-251 -- for 2006-w36-4/2006-251
            > > 2006-w36-4/251 -- for 2006-w36-4/2006-251

            > And "Mutual agreement" is required here. ............................

            I do not think that "mutual agreement" is required for these
            omissions. The text says:
            [4.4.5p5]
            The use of a representation needs to be agreed by the partners in
            information interchange if the use of any of its constituent
            parts needs to be agreed by these partners.
            The constituent parts of eg
            2006-09-07/-08
            do not need such an agreement, so why is mutual agreement needed?

            > ........................................ However, I would not use any
            > of the "incomplete" representations. They seem to me to be more
            > useful to human-readability and less useful to computer-
            > understandability. The computer doesn't mind reading and writing a
            > few more bytes.

            You are right that 2006-09-07/-08 is easy to read for a human;
            but 2006-w36-4/251 definitely is not. Anyway, even if if they
            are only useful for communication with humans, computers must
            be able to produce and accept such notations, so a precise
            specification is needed. (And a few bytes more or less DO matter
            in some applications!)

            > > [c] By "mutual agreement", a duration can be given as eg
            > > P0001-02-03
            > > to indicate "1 year + 2 months + 3 days". This would allow
            > > P-0001-02-03
            > > but what does it mean? "durations" must not be negative
            > > in [ISO 8601:2004].

            > Hmmm... no, the standard says "PYYYY ..." , not "P+-YYYY ..."

            But the format you are quoting is described as:
            [4.4.3.3p2]
            The complete representation of the expression for
            duration in the alternative format is as follows:
            and the notation with the - is not a "complete representation"
            but an "expanded representation". I do not see where
            [ISO 8601:2004] rules out the use of expanded representations
            of dates in the alternative format for durations.
            Can you give chapter and verse?

            > > [d] A Note to the definition of "duration" says that leap seconds
            > > must be "accounted" for in the length of epoch intervals.
            > > Even though Notes are not normative, does this mean that
            > > the end point of
            > > 2005-12-31T12Z/P1D
            > > shall be 2006-01-01T11:59:59Z rather than
            > > 2006-01-01T12:00:00Z.
            > > (A leap second occured at 2005-12-31T23:59:60Z.)
            >
            > Unclear in :2000, :2004 is better, section 2.2.7 says
            > "
            > 2.2.7
            > day
            > <duration> duration of a calender day
            >
            > NOTE The term "day" applies also to the duration of any time interval
            > which starts at a certain time of day at a certain calendar day and
            > ends at the same time of day at the next calendar day.
            > "

            You make an interesting point: P1D is a "nominal duration",
            whose length in seconds may vary, so that it is possible that
            2005-12-31T12Z/P1D ends at 2006-01-01T12:00:00Z
            But P24H is not a "nominal duration" but it is 86400 s exactly,
            so that
            2005-12-31T12Z/P24H ends at 2006-01-01T11:59:59Z
            Wow!

            > So I wouldn't worry about them.

            I don't. What really bothers me a bit is the quality of the
            specifications in [ISO 8601]. Leaving basic things open to
            interpretation, and even not specifying exactly which notations
            are allowed and which are not (eg, with a formal grammar like BNF
            as is common in computer science) makes it hard to adopt the full
            scope of ISO 8601, beyond the most simple calendar date and time
            notations.
            Do you agree with me here?

            Thanks again!

            Michael Deckers
          • Michael Deckers
            ... Of course, it should be 2005-12-31T12Z/PT24H. Michael Deckers
            Message 5 of 12 , Sep 15, 2006
            View Source
            • 0 Attachment
              On 2006-09-15, Michael Deckers penned without thinking:

              > But P24H is not a "nominal duration" but it is 86400 s exactly,
              > so that
              > 2005-12-31T12Z/P24H ends at 2006-01-01T11:59:59Z
              > Wow!

              Of course, it should be 2005-12-31T12Z/PT24H.

              Michael Deckers
            • piebaldconsult
              ... I understood the question not to relate to a zero-length interval, but to a representation in which one or the other value is empty (not specified) such as
              Message 6 of 12 , Sep 18, 2006
              View Source
              • 0 Attachment
                > > > Can a time interval be empty?

                I understood the question not to relate to a zero-length interval,
                but to a representation in which one or the other value is empty (not
                specified) such as "2006-09-18/" or "/2006-09-18". These are not
                allowed. Certainly zero-length intervals are allowed.


                > The constituent parts of eg
                > 2006-09-07/-08
                > do not need such an agreement, so why is mutual agreement needed?

                I, for one, have no idea what "2006-09-07/-08" means.

                > You are right that 2006-09-07/-08 is easy to read for a human;
                > but 2006-w36-4/251 definitely is not. Anyway, even if if they
                > are only useful for communication with humans, computers must
                > be able to produce and accept such notations, so a precise
                > specification is needed. (And a few bytes more or less DO matter
                > in some applications!)

                Bytes (spent storing and transmitting) probably matter less than
                clock cycles (spent determining which format is used) and both matter
                less than time and effort spent maintaining a system. Limit the
                number of allowed formats and save yourself a lot of headache.


                > > > but what does it mean? "durations" must not be negative
                > > > in [ISO 8601:2004].
                >
                > > Hmmm... no, the standard says "PYYYY ..." , not "P+-YYYY ..."
                >
                > But the format you are quoting is described as:
                > [4.4.3.3p2]
                > The complete representation of the expression for
                > duration in the alternative format is as follows:
                > and the notation with the - is not a "complete representation"
                > but an "expanded representation". I do not see where
                > [ISO 8601:2004] rules out the use of expanded representations
                > of dates in the alternative format for durations.
                > Can you give chapter and verse?

                Well, you seem to be correct, but :2004 section 2.1.6 says a duration
                is a "non-negative quantity attributed to a time interval...".


                > Do you agree with me here?

                Yeah, but I wouldn't want to try to write a BNF for it, your
                wonderful railroad diagram in complicated enough.
              • piebaldconsult
                ... Which section of which version? I don t see that verbiage. Section 2.1.6 in version :2004 has NOTE 1 In the case of discontinuites in the time scale,
                Message 7 of 12 , Sep 18, 2006
                View Source
                • 0 Attachment
                  > > > [d] A Note to the definition of "duration" says that leap seconds
                  > > > must be "accounted" for in the length of epoch intervals.

                  Which section of which version? I don't see that verbiage.

                  Section 2.1.6 in version :2004 has

                  "
                  NOTE 1 In the case of discontinuites 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.

                  Given 23:55:00 and adding PT10M for most nights will result in
                  00:05:00, but on a leap-second night we have to consider the
                  possibility that the result is 00:04:59, yes?

                  I, for one, don't want that result, so I'll add the "duration of the
                  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.
                • Michael Deckers
                  Thanks for your detailed answers. ... Yes. Such intervals would be empty if the end point is not considered part of the interval (which it normally is,
                  Message 8 of 12 , Sep 21, 2006
                  View Source
                  • 0 Attachment
                    Thanks for your detailed answers.

                    piebaldconsult wrote:

                    > ........ Certainly zero-length intervals are allowed.

                    Yes. Such intervals would be empty if the end point is
                    not considered part of the interval (which
                    it normally is, according to a NOTE in [2.1.3].)

                    > I, for one, have no idea what "2006-09-07/-08" means.

                    Sorry, I did not explain: I just tried to follow ISO 8601:2004
                    with the recipe
                    [4.4.5] Representations other than complete
                    ...
                    In the representation of time intervals in accordance with 4.4.1 a),
                    -- that is, in the form start/end
                    higher order time elements may be omitted from the expression
                    following the solidus (i.e. the representation for “end of time
                    interval”); in such a case it shall be assumed that the
                    corresponding time elements from the “start of time interval”
                    expression apply (e.g. if [YYYYMM] are omitted, the end of the time
                    interval is in the same calendar year and calendar month as the
                    start of the time interval);
                    ...
                    So what I probably should have written first is
                    2006-09-07/--08
                    as a representation for the time interval 2006-09-07/2006-09-08,
                    omitting the "time elements" year and month from 2006-09-08.
                    Here, no separators are omitted since separators are not
                    "time elements".

                    On the other hand, doesn't a separator have to separate time
                    elements, as suggested by:
                    [3.4.4] Characters used as separators
                    In representations the following characters are used as separators:
                    [-] (hyphen): to separate the time elements “year” and “month”,
                    “year” and “week”, “year” and “day”, “month” and “day”, and
                    “week” and “day”;
                    So maybe we have to omit the separators and write 2006-09-07/08
                    for the same interval. This is easy to interpret for a human
                    reader. Or is "separation of time elements" only one use of
                    separators, among several; so that, possibly, both notations are
                    allowed? And, finally, what about 2006-09-07/-08 where one
                    separator is retained and one is omitted? 2006-09-07/08 and
                    2006-09-07/---08 were clearly allowed in ISO 8601:2000.

                    Anyway, ISO 8601 does not specify precisely enough the allowed
                    abbreviations of extended formats for time intervals specified
                    with start and end, so that they will not be used very much.
                    (And this may even have been intended by the authors.)

                    > Bytes (spent storing and transmitting) probably matter less than
                    > clock cycles (spent determining which format is used) and both matter
                    > less than time and effort spent maintaining a system. .........

                    The size of data packets does matter in several applications I have
                    seen -- mainly for financial reasons: bandwidth and storage space
                    do not come for free. But you are right -- if data size is a concern
                    for such reasons then the ISO 8601 formats should not be used anyway.

                    However, shorter formats can also also increase legibility -- if
                    you have a column with hundreds of intervals like
                    2006-09-21T12:01/2006-09-21T12:14
                    none of which contains a midnight, then an abbreviated format like
                    2006-09-21T12:01/T12:14
                    may well make things easier to read. It is for this reason that
                    an abbreviated extended format might be useful, I guess.

                    > ..................................................... Limit the
                    > number of allowed formats and save yourself a lot of headache.

                    Yes, in most applications, the datetime formats will be restricted to
                    a small number, and the new format representations of ISO 8601:2004
                    even allow for their specification at the time of data exchange.
                    But the wider the selection of possible formats to choose from, the
                    better the format can be adapted to the requirements of a particular
                    application.

                    > Yeah, but I wouldn't want to try to write a BNF for it, your
                    > wonderful railroad diagram in complicated enough.

                    Thanks. I am working on a such a grammar for IS 8601:2004, and
                    my questions all arose during that work.

                    Michael Deckers
                  • Michael Deckers
                    ... You are perfectly right, I stand corrected. I should not have put the word, accounted , within quotes. ... Of course you can. The question is whether it
                    Message 9 of 12 , Sep 21, 2006
                    View Source
                    • 0 Attachment
                      On 2006-09-18, piebaldconsult wrote:

                      > > [d] A Note to the definition of "duration" says that leap seconds
                      > > must be "accounted" for in the length of epoch intervals.
                      >
                      > Which section of which version? I don't see that verbiage.

                      You are perfectly right, I stand corrected. I should not have put
                      the word, "accounted", within quotes.

                      > Section 2.1.6 in version :2004 has
                      > "
                      > 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.

                      Of course you can. The question is whether it can be done while
                      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
                      the application.

                      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
                      2005-12-31T23:59:59Z/2005-12-31T24:00:00Z
                      is PT02S, I have to assume.

                      > Given 23:55:00 and adding PT10M for most nights will result in
                      > 00:05:00, but on a leap-second night we have to consider the
                      > possibility that the result is 00:04:59, yes?

                      For UTC timestamps, I think that's what the standard says, 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 the
                      > 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.

                      Nor do I want that result with UTC in most, if not all, cases. I am
                      just not sure whether this would still conform with ISO 8601:2004.

                      Regards

                      Michael Deckers
                    • piebaldconsult
                      ... I m still not sure we re on the same page linguistically here. I m not even sure what I said was clear. How about: An interval may be a representation of
                      Message 10 of 12 , Sep 28, 2006
                      View Source
                      • 0 Attachment
                        > > ........ Certainly zero-length intervals are allowed.
                        >
                        > Yes. Such intervals would be empty if the end point is
                        > not considered part of the interval (which
                        > it normally is, according to a NOTE in [2.1.3].)

                        I'm still not sure we're on the same page linguistically here.
                        I'm not even sure what I said was clear.

                        How about:
                        "An interval may be a representation of a duration of zero units of
                        time."

                        Such as "2006-09-01T00:00:00/2006-09-01T00:00:00"

                        ISO 8601 allows the second part of the value to be shortened by
                        omitting the "higher order components" it has in common with the
                        first part.

                        So "2006-09-01T00:00:00/2006-09-01T12:00:00"
                        Can be "2006-09-01T00:00:00/T12:00:00"

                        (And of course the trailing <:00>s can be removed from both parts.)

                        It's shortest form (remember I don't like "basic format") would
                        be: "2006-09-01/T12"

                        <aside>Which gets into the whole "but you're mixing basic and
                        extended format" argument.</aside>

                        So the shortest form of that first (zero-duration) value could
                        logically be: "2006-09-01/"

                        This is what I understood you to be asking about -- the second part
                        is "empty". I answered that this is not compliant (or attempted to
                        anyway), but I'm going to <em>change my answer!</em> I see nothing
                        in :2004 section 4.4.5 (:2000 5.5.5) that limits how many of
                        the "higher-order components" may be omitted or that at least one
                        component must be present, only that it not be complete, which it
                        obviously isn't.
                      • piebaldconsult
                        ... Even if ISO 8601 says you must, the W3C probably has more real influence and http://www.w3.org/TR/xmlschema11-2/#vp-dt-second says, in part: Leap seconds
                        Message 11 of 12 , Sep 28, 2006
                        View Source
                        • 0 Attachment
                          > Nor do I want that result with UTC in most, if not all, cases. I am
                          > just not sure whether this would still conform with ISO 8601:2004.

                          Even if ISO 8601 says you must, the W3C probably has more real
                          influence and

                          http://www.w3.org/TR/xmlschema11-2/#vp-dt-second

                          says, in part:

                          "
                          Leap seconds are not supported by the types defined here.
                          "


                          Pro-leap-second readers should note, it also says:

                          "
                          When leap seconds are introduced, the last minute in the day has more
                          than sixty seconds.
                          "

                          Which may not be in keeping with ISO 8601... do they mean the last
                          minute in the day in the local zone? That's no good, it has to be the
                          same second everywhere, as ISO 8601 says, it's 23:59:60Z (regardless of
                          local zone), things get even screwier otherwise.
                        • piebaldconsult
                          ... Ah, yes, that again. (This is in ISO 8601:2004, it clears up ISO 8601:2000 section 3.17 a bit.) 2.1.3 time interval part of the time axis limited by two
                          Message 12 of 12 , Sep 28, 2006
                          View Source
                          • 0 Attachment
                            > > ........ Certainly zero-length intervals are allowed.
                            >
                            > Yes. Such intervals would be empty if the end point is
                            > not considered part of the interval (which
                            > it normally is, according to a NOTE in [2.1.3].)

                            Ah, yes, that again. (This is in ISO 8601:2004, it clears up ISO
                            8601:2000 section 3.17 a bit.)

                            "
                            2.1.3
                            time interval
                            part of the time axis limited by two points
                            [IEC 60050-111]
                            NOTE A time interval comprises all instants between two limiting
                            instants and, unless otherwise stated, the limiting instants themselves.
                            "

                            So, how long is an instant?

                            "
                            2.1.2
                            instant
                            point on the time axis
                            [IEC 60050-111]
                            NOTE An instantaneous event occurs at a specific instant.
                            "

                            I take this to mean that an instant, like a point in space, has no
                            dimension, no size, zero duration. (But I still wonder how a whole
                            bunch of things of zero size can add up to something with non-zero
                            size.)

                            There would be problems otherwise, not the least of which would be that
                            "2006-09-01T00:00:00.000Z/2006-09-01T00:00:00.000Z" (for instance)
                            would _not_ have zero duration when logically it should be the exact
                            same interval as "2006-09-01T00:00:00.000Z/PT0S".

                            If not, what would you choose, and why? And might it be application-
                            specific? Let's consider the interval:
                            "2006-09-01T00:00:00.000Z/2006-09-01T00:00:00.001Z"

                            What's its duration?
                            A) PT0.001S -- this is with a zero-length instant
                            B) PT0.002S -- this is with a one millisecond instant
                            C) PT1.001S -- this is with a one second instant
                            D) None of the above

                            <rhetorical>
                            Is it valid to argue that duration is defined in terms of instants
                            therefore instants can't have duration?
                            (I may be a cunning linguist, but I'm no master debater.)
                            </rhetorical>

                            Of course, "by mutual...interchange" can agree that for their purposes,
                            an instant is some non-zero duration, perhaps one second. But also
                            consider the benefit of a context-sensitive duration whereby the finest
                            granularity used in the representation determines the duration of an
                            instant _for_that_representation_:

                            In "2006/2007" the instant 2007 would have a duration of P1Y, resulting
                            in a total duration of P2Y. (But that's extreme.)

                            Of more use would be "2006-09-01/2006-09-30", which would have the
                            expected total duration of P30D. (A zero-duration instant would reduce
                            it to P29D, while a one second instant would make it P29D1S, which is
                            most unexpected. You wouldn't expect P29D0.001S either.)

                            Similar to that would be to agree that missing low-order components in
                            the first part are assumed to be 0, while in the second part they are
                            the high values for the component so that
                            "2006-09-01/2006-09-01" equates to
                            "2006-09-01T00:00:00Z/2006-09-01T23:59:59Z"

                            But this scheme would have trouble with leap seconds, even if T24:00
                            were used. And also the seconds component can have unlimited decimal
                            places.

                            It would also get hosed when a "backward" interval is specified, as in
                            "2006-09-30/2006-09-01".

                            So please forget I even mentioned it.
                          Your message has been successfully submitted and would be delivered to recipients shortly.