Do the recent new members have no questions?

Did the past posts and files answer the questions?

On the Internet, the notation of times and dates has always been
problematic. In particular, the format of Internet E-mail messages,
as defined in 1982-08-13 (with some later modifications) by RFC 822
remained valid (which is still valid as an Internet standard) for a
very long time. specifies a relatively uniform notation for date and
time. It allowed some variation, but the most common alternative was
something like
Fri, 8 May 1998 15:57:33 +0300 (EET DST)
There was enough variation to make it difficult to write simple
programs for processing such data, too little variation to please
everyone. In 2001-04, RFC 2822 was published as a successor to RFC
822. It restricted the recommended date and time formats to the
format exemplified above. But still this doesn't comply with ISO8601,
is there any attempt to change it. Anybody could shed any light
regarding this.

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

I see mentions of the date format YYYY-DDD and time formats that
include decimal fractions of a second.

Shall I assume that YYYY-DDD.fffff (where fffff is decimal fractions
of a day) is not an accepted format?

What would be the process for getting something like this added to a
later revision of ISO8601?

Decimal fractions of an hour are commonly used in payroll scenarios. I
don't know of an application of decimal fractions of a day but I'm
sure there are some.

Just for curiousity's sake,

Bill Somebody-or-other
(New Member)

I work for a company which offers internet applications/services for
commerce in an industrial setting.

For many of the transactions, the delivery date is specificed and this
in normal given as a week period.

Our site has five languages.
In english, '2006-W35' is of course fine; however, in other languages
another separator may be more natural.  Below I have listed the
suggestions:

Italian: '2006-S35'
French: '2006-S35'
Spanish: '2006-S35'
German: '2006-KW35'

Does anyone have some input.  We are commited to being compliant with
ISO-8601.

Thanks in advance,
David

I believe astronomy could make good use of fractions of day. I often
have wished an akternative time-of-day scheme would be decimal days,
like 1999-12-31.5 for noon on 1999-12-31.

On 11/09/06, Bill Somebody-or-Other <dygituljunky@...> wrote:
>
>
>
>
>
>
>
> I see mentions of the date format YYYY-DDD and time formats that
>  include decimal fractions of a second.
>
>  Shall I assume that YYYY-DDD.fffff (where fffff is decimal fractions
>  of a day) is not an accepted format?
>
>  What would be the process for getting something like this added to a
>  later revision of ISO8601?
>
>  Decimal fractions of an hour are commonly used in payroll scenarios. I
>  don't know of an application of decimal fractions of a day but I'm
>  sure there are some.
>
>  Just for curiousity's sake,
>
>  Bill Somebody-or-other
>  (New Member)

--- In ISO8601@yahoogroups.com, "contadino_usa" <david_hain@...>
wrote:
> Our site has five languages.
> In english, '2006-W35' is of course fine; however, in other
languages
> another separator may be more natural.  Below I have listed the
> suggestions:
>
> Italian: '2006-S35'
> French: '2006-S35'
> Spanish: '2006-S35'
> German: '2006-KW35'
>
> Does anyone have some input.  We are commited to being compliant
with
> ISO-8601.
>
> Thanks in advance,
> David
>

ISO 8601 is an International standard and it specifies "W" as the
character designator which must precede a week number.  The date and
time format is primarily numeric to avoid language difficulties and
only a few other separator and designator symbols are permitted (and
in some cases, required). Nothing else is permitted. If you use other
symbols, you are not compliant. 8601 does not define the "W" as an
acronym or abbreviation; it is a character designator (it "just
happens" to have some special relevance in English, but "Z" for UTC
time does not have much relevance in English).

The 2000 final draft (I don't have access to the 2004 version)
specifically allows decimal hour, minute, or second representation.
If you use decimal hour, you obviously can't use minutes too; lower
order components must be omitted.

It does not specifically allow a decimal day fraction

--- In ISO8601@yahoogroups.com, "Bill Somebody-or-Other"
<dygituljunky@...> wrote:
>
> I see mentions of the date format YYYY-DDD and time formats that
> include decimal fractions of a second.
>
> Shall I assume that YYYY-DDD.fffff (where fffff is decimal fractions
> of a day) is not an accepted format?
>
> What would be the process for getting something like this added to a
> later revision of ISO8601?
>
> Decimal fractions of an hour are commonly used in payroll
scenarios. I
> don't know of an application of decimal fractions of a day but I'm
> sure there are some.
>
> Just for curiousity's sake,
>
> Bill Somebody-or-other
> (New Member)
>

>    [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.

That is correct, date values are not allowed to have fractional parts.

How a value is presented to a human user may/should not be the same as
the underlying computer-centric value.

In message <edn0e5+k1cu@eGroups.com>, siddharthab19
<siddharthab19@...> writes
>On the Internet, the notation of times and dates has always been
>problematic. In particular, the format of Internet E-mail messages,
>as defined in 1982-08-13 (with some later modifications) by RFC 822
>remained valid (which is still valid as an Internet standard) for a
>very long time. specifies a relatively uniform notation for date and
>time. It allowed some variation, but the most common alternative was
>something like
>Fri, 8 May 1998 15:57:33 +0300 (EET DST)
>There was enough variation to make it difficult to write simple
>programs for processing such data, too little variation to please
>everyone. In 2001-04, RFC 2822 was published as a successor to RFC
>822. It restricted the recommended date and time formats to the
>format exemplified above. But still this doesn't comply with ISO8601,
>is there any attempt to change it. Anybody could shed any light
>regarding this.
>

AFAIR during work on the successor to RFC822 (ietf-drums working group)
there was a proposal to adopt ISO8601 for the Date: header.  However,
this proposal was rejected on the grounds of compatibility, there is
just too much email software out there that would break.  Indeed any
change that was thought likely to break existing software was rejected.

(I can't find the ietf-drums mailing list archive to verify my memory).

The place to raise this is probably in the ietf-822 mailing list, but
I'm sure the same objection would still stand today.

Regards
--
Paul Overell         Internet Platform Development Manager, Thus plc

--- In ISO8601@yahoogroups.com, "piebaldconsult" <PIEBALDconsult@...>
wrote:
>
> How a value is presented to a human user may/should not be the same as
> the underlying computer-centric value.
>

Our system does provide an XLM Order message and for this there is no
disucussion - We send the week date according to the ISO standard plus
we also specify the format as well in the message.

My question was regarding the UI of our application - thus the
presentation of the week date to a human user and more specifically a
German or Italian user.

-David

In message <edn0e5+k1cu@eGroups.com>, siddharthab19
<siddharthab19@...> writes
>On the Internet, the notation of times and dates has always been
>problematic. In particular, the format of Internet E-mail messages,
>as defined in 1982-08-13 (with some later modifications) by RFC 822
>remained valid (which is still valid as an Internet standard) for a
>very long time. specifies a relatively uniform notation for date and
>time. It allowed some variation, but the most common alternative was
>something like
>Fri, 8 May 1998 15:57:33 +0300 (EET DST)
>There was enough variation to make it difficult to write simple
>programs for processing such data, too little variation to please
>everyone. In 2001-04, RFC 2822 was published as a successor to RFC
>822. It restricted the recommended date and time formats to the
>format exemplified above. But still this doesn't comply with ISO8601,
>is there any attempt to change it. Anybody could shed any light
>regarding this.
>

AFAIR during work on the successor to RFC822 (ietf-drums working group)
there was a proposal to adopt ISO8601 for the Date: header.  However,
this proposal was rejected on the grounds of compatibility, there is
just too much email software out there that would break.  Indeed any
change that was thought likely to break existing software was rejected.

(I can't find the ietf-drums mailing list archive to verify my memory).

The place to raise this is probably in the ietf-822 mailing list, but
I'm sure the same objection would still stand today.

Regards
--
Paul Overell         Internet Platform Development Manager, Thus plc

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

Pl. mention is there any axiom for-
  1. calculation of time span (BC & AD)
  2. one-one correspondance between Number-line & Time-line.
  3. Leap-Year (BC/AD)
  4. Zero-Year & Zero-AD.
  5. Calendar in BC years(1,2,3,...BC) & Zero-AD
                              nilamber biswal

In message <edn0e5+k1cu@eGroups.com>, siddharthab19
<siddharthab19@...> writes
>On the Internet, the notation of times and dates has always been
>problematic. In particular, the format of Internet E-mail messages,
>as defined in 1982-08-13 (with some later modifications) by RFC 822
>remained valid (which is still valid as an Internet standard) for a
>very long time. specifies a relatively uniform notation for date and
>time. It allowed some variation, but the most common alternative was
>something like
>Fri, 8 May 1998 15:57:33 +0300 (EET DST)
>There was enough variation to make it difficult to write simple
>programs for processing such data, too little variation to please
>everyone. In 2001-04, RFC 2822 was published as a successor to RFC
>822. It restricted the recommended date and time formats to the
>format exemplified above. But still this doesn't comply with ISO8601,
>is there any attempt to change it. Anybody could shed any light
>regarding this.
>

AFAIR during work on the successor to RFC822 (ietf-drums working group)
there was a proposal to adopt ISO8601 for the Date: header.  However,
this proposal was rejected on the grounds of compatibility, there is
just too much email software out there that would break.  Indeed any
change that was thought likely to break existing software was rejected.

(I can't find the ietf-drums mailing list archive to verify my memory).

The place to raise this is probably in the ietf-822 mailing list, but
I'm sure the same objection would still stand today.

Regards
--
Paul Overell         Internet Platform Development Manager, Thus plc

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

--- In ISO8601@yahoogroups.com, "siddharthab19" <siddharthab19@...>
wrote:
>
> On the Internet, the notation of times and dates has always been
> problematic. In particular, the format of Internet E-mail
messages,
> as defined in 1982-08-13 (with some later modifications) by RFC
822
> remained valid (which is still valid as an Internet standard) for
a
> very long time. specifies a relatively uniform notation for date
and
> time. It allowed some variation, but the most common alternative
was
> something like
> Fri, 8 May 1998 15:57:33 +0300 (EET DST)
> There was enough variation to make it difficult to write simple
> programs for processing such data, too little variation to please
> everyone. In 2001-04, RFC 2822 was published as a successor to RFC
> 822. It restricted the recommended date and time formats to the
> format exemplified above. But still this doesn't comply with
ISO8601,
> is there any attempt to change it. Anybody could shed any light
> regarding this.

AFAIR during work on the successor to RFC822 (ietf-drums working
group) there was a proposal to adopt ISO8601 for the Date: header.
However, this proposal was rejected on the grounds of compatibility,
there is just too much email software out there that would break.
Indeed any change that was thought likely to break existing software
was rejected.

(I can't find the ietf-drums mailing list archive to verify my
memory, it may have been the usefor working group for usenet news,
but the same argument applies).

The place to raise this is probably in the ietf-822 mailing list,
but I'm sure the same objection would still stand today.

Regards

Paul Overell

Hi, David,

According to ISO standard I am understanding these characters used for
codifying only as conventions with no idiomatic meaning of use. So, if
you want to be as complaint as you declared, I am thing you should
follow the usage this standard specifies.

--
The Collector

--- In ISO8601@yahoogroups.com, "nilamberbiswal" <nilamberbiswal@...>
wrote:
>
> Pl. mention is there any axiom for-
>  1. calculation of time span (BC & AD)
>  2. one-one correspondance between Number-line & Time-line.
>  3. Leap-Year (BC/AD)
>  4. Zero-Year & Zero-AD.
>  5. Calendar in BC years(1,2,3,...BC) & Zero-AD
>                              nilamber biswal
>

I'm not sure what you are asking.

ISO8501 mandates the Gregorian calendar but no one really used it
before 1582, they used the Julian calendar. After Caesar's
assassination, the priests screwed up leap year for a few years,
later corrected by Augustus, so prior to 8 AD, it is not clear what
years were observed as leap year at the time. But 8601 just backcasts
the rules of the Gregorian calendar into the past.

Year 0001 = 1 AD, and so on for all positive years.

The AD/BC nomenclature arose before zero was commonly used. ISO 8601
uses the same convention as astronomers:
Year 0000 = 1 BC
year -0001 = 2 BC, etc.

Numeric years 0000, -0004, etc are Gregorian leapyears, but they are
1 BC, 5 BC, etc.  Time spans are most easily calculated using numeric
years and avoiding AD/BC problems.

> >  >   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.

> >  > [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.

ISO 8601 does not allow for decimal fractions of the day, only hours,
minutes and seconds.  Astronomers do, indeed, use fractional days.
The ordinal date format YYDDD.ffffffff is used by NASA and NORAD as
part of their TLE standard for tracking satellites, as explained at
http://science.nasa.gov/Realtime/rocket_sci/orbmech/state/2line.html
(note that they still use 2-digit years, while ISO now permits no less
than 4 digits).

See http://cfa-www.harvard.edu/iau/lists/LastCometObs.html for
examples of calendar dates with fractional days, including both
all-numeric dates such as "2006 09 21.05" and dates with month-names
such as "2006 Sept. 24.01".  Neither of these exactly match ISO,
although the numeric one comes close.

There are also various day-only dates which include decimal fractions
of a day, most notably astronomers' Julian Dates (i.e. days counted
from the beginning of the Julian Period (4713 BCE)) and Microsoft
Excel's serial dates (1900 CE).  You can find lots of references
online for these.

Fractional hours are supported by ISO, in the form YYYY-MM-DDTHH.hh
(when combined with calendar date) or YYYY-DDDTHH.hh (when combined
with ordinal date), but I've never seen decimal hours used with ISO
dates in actual payroll usage.

I've suggested supporting fractional days here, myself.  But to
actually get it done, I think that you have to contact your country's
ISO representatives, and have them propose it to the international
committee in charge of this particular standard.

John Hynes
2006 Sept. 24.223 UT

--- In ISO8601@yahoogroups.com, "Bill Somebody-or-Other"
<dygituljunky@...> wrote:
>
> I see mentions of the date format YYYY-DDD and time formats that
> include decimal fractions of a second.
>
> Shall I assume that YYYY-DDD.fffff (where fffff is decimal fractions
> of a day) is not an accepted format?
>
> What would be the process for getting something like this added to a
> later revision of ISO8601?
>
> Decimal fractions of an hour are commonly used in payroll scenarios. I
> don't know of an application of decimal fractions of a day but I'm
> sure there are some.
>
> Just for curiousity's sake,
>
> Bill Somebody-or-other
> (New Member)

> The ordinal date format YYDDD.ffffffff is used by NASA and NORAD as

The formats:

YYYY-MM-DD._ff
YYYY-DDD._ff
YYYY-WwwD._ff

seem reasonable enough (though I don't expect I'd ever have need of
them), but...

If the fractional part of a day represents a time-of-day then
oughtn't it to be preceded by a T? If so, then wouldn't it also
require at least one digit before the decimal point (ummm... comma)?

2006-123T0,5

If so then what does 2006-123T1,5 mean? It must be invalid.

At any rate, this would seem to introduce an additional scheme for
time-of-day (which may well be a good thing). Maybe we just need to
decide on a seperator (other than the T)?

Likewise, what if I wanted to specify time-of-day just by minutes or
seconds?

We may need four methods of specifying time-of-day:

HH[:MM[:SS]][,_ff]    (currently the only method)
MM[:SS][,_ff]
SS[,_ff]
,_ff

I think each would require its own seperator.

piebaldconsult said:

> > The ordinal date format YYDDD.ffffffff is used by NASA and NORAD as
>
> The formats:
>
> YYYY-MM-DD._ff
> YYYY-DDD._ff
> YYYY-WwwD._ff
>
> seem reasonable enough (though I don't expect I'd ever have need of
> them), but...
>
> If the fractional part of a day represents a time-of-day then
> oughtn't it to be preceded by a T? If so, then wouldn't it also
> require at least one digit before the decimal point (ummm... comma)?
>
> 2006-123T0,5

No. The T delimiter separates the Date component from the Time component.
If a fractional-day representation were to be allowed, the fraction is a
fraction of a Date.

> If so then what does 2006-123T1,5 mean? It must be invalid.

Indeed.

> At any rate, this would seem to introduce an additional scheme for
> time-of-day (which may well be a good thing). Maybe we just need to
> decide on a seperator (other than the T)?
>
> Likewise, what if I wanted to specify time-of-day just by minutes or
> seconds?

I can see no good reason for allowing this. Assuming you're referring to
(e.g.) minutes in excess of one hour, then what is gained by not
transforming them to the hh:mm:ss format?

What is gained anyway by allowing fractions of a day? You can always
multiply the fraction by 86400 to get seconds and fractions thereof(*),
and the calculation is reversible without loss of significance. Remember
that ISO8601 is a machine:machine protocol, so it's not unreasonable to
expect transformations at one end or the other, or even both.

The standard is NOT intended to embrace any old format that anyone cares
to cook up. It's intended to replace the former miscellany with a well-
defined, minimally-redundant, coherent structure.

(*) Let's not get into leap seconds: I decline to believe that anyone
uses "0.001 days" to mean "1 minute 26.401 seconds on 2005-12-31".

> We may need four methods of specifying time-of-day:
>
> HH[:MM[:SS]][,_ff]    (currently the only method)

And long may it remain so.

At 2006-09-26 09:38 +0100, Fred Bone wrote:
>(*) Let's not get into leap seconds: I decline to believe that anyone
>uses "0.001 days" to mean "1 minute 26.401 seconds on 2005-12-31".

IMHO this is the main reason why ISO 8601 cannot support fractions of
a day.  Hours always have 3600 SI seconds.  Days may have between
86399 and 86401 seconds.  You'd need to branch into an area of mutual
agreement where either  the chosen time scale had no leap seconds, or
the accuracy of the fractional days was "good enough".

--
Pete Forman                -./\.-  Disclaimer: This post is originated
WesternGeco                  -./\.-   by myself and does not represent
pete.forman@...    -./\.-   the opinion of Schlumberger or
http://petef.port5.com           -./\.-   WesternGeco.

> > 2006-123T0,5
>
> No. The T delimiter separates the Date component from the Time
component.
> If a fractional-day representation were to be allowed, the fraction
is a
> fraction of a Date.

Which means the time _within_ that day.

> and the calculation is reversible without loss of significance.
>Remember
> that ISO8601 is a machine:machine protocol, so it's not
unreasonable to
> expect transformations at one end or the other, or even both.

That is also the case of the week and ordinal date formats as well.
Why have three date formats when the computer can easily transform
between them?

Which is probably why when the W3C was "inspired" to create their own
formats, they chose to support only the calendar date format.

--- In ISO8601@yahoogroups.com, Pete Forman <pete.forman@...> wrote:
> IMHO this is the main reason why ISO 8601 cannot support fractions of
> a day.  Hours always have 3600 SI seconds.  Days may have between
> 86399 and 86401 seconds.  You'd need to branch into an area of mutual
> agreement where either  the chosen time scale had no leap seconds, or
> the accuracy of the fractional days was "good enough".

Hours do NOT always have 3600 SI seconds.  Sometimes they have 3601.
Hypothetically, they can also have 3599.  Likewise, a minute may have
59, 60 or 61 seconds.  I do not see how this would cause more of a
problem for fractional days than it already does for fractional hours.
  In fact, the difference between 1/86400 and 1/86401 is much smaller
than between 1/3600 and 1/3601, let alone 1/60 and 1/61.

John Hynes
www.decimaltime.org
2006-09-27T10.5Z

--- In ISO8601@yahoogroups.com, "piebaldconsult" <PIEBALDconsult@...>
wrote:
> If the fractional part of a day represents a time-of-day then
> oughtn't it to be preceded by a T? If so, then wouldn't it also
> require at least one digit before the decimal point (ummm... comma)?
>
> 2006-123T0,5

That would be a half-hour past midnight, i.e. 00:30, although it
should properly be written with two 0s.

Adding an extra digit would be redundant, since the whole number part
of the fraction is the day (of month, week or year).  If fractional
days were to be permitted, then the time of day should not be
permitted with the date representation.  That is, a decimal fraction
is permitted only for the lowest-order component, a date with a
fractional day could not also include a time of the day
representation, since the highest-order component of the latter is the
hour.

Likewise, when representing time of the day with a decimal fraction of
the hour, you would not represent 00:30 it as :0,5 or as 0,5: but as
00,5.  The time designator T is always preceded by the day, and always
followed by the hour.  Thus, a representation with a fractional day
would be date-only, even though the fraction could be converted to a
time of the day.

Which is all academic, since decimal fractions of days is not
permitted by the standard, actual use thereof not withstanding.  I
would also point out that decimal fractions of years are also used
(although they do not correspond exactly to the Gregorian calendar).
Decimal fractions of months would be difficult to implement, however.

John Hynes
www.decimaltime.org
2006-09-27T11,0Z