Emend ISO 8601:2000

                             u-8601-2.txt  

    (c) J R Stockton    www.merlyn.demon.co.uk    >= 2005-07-21


Initially, about 2005-01-27 -


I have been sent a PDF copy of a late draft of ISO 8601:2000.

I would have liked the following points of varying significance to have
been taken into consideration in drafting any later version of the
Standard, but :-

  * I've not been able to establish contact with anybody relevant;
  * ISO 8601:2004 has been released (I've not seen it).

Of course, ISO 8601:2004 may differ in these respects.


*** ADDED 2007-02-10 : I now have a copy of ISO 8601:2004 and intend
to update this page soon.
*** ADDED 2008-09-19 : No, a new page u-8601-3.txt



(A) : Introduction

Contains "national boundaries" - "national or regional" might be more
complete.  Sec 3.1.3 uses "regional".



(B) : Section 3.1 :

Para 1 : I'd have expected BIPM's name to have had those letters in
upper case.

Note 3 : IERS's URL is not underlined.



(C) : Section 3.7 :

If any places in the time zone one hour to the West of Greenwich follow
the EU Summer (Daylight Saving) Time Rules, they will have a Spring day
that starts at [0100] - I think.

I suggest that there should be a specific reference to Summer (Daylight
Saving) Time in or near Note 2, because it is so easily forgotten.



(E) : Section 3.11 :

"In the Gregorian calendar" may be superfluous; the Julian is also thus
constructed.



(F) : Section 3.16 :

Note 2 : "... as month." to "... as a month." ?

Sec 3.17 likewise, 3.25 (twice), 3.28, 3.30.



(G) : Section 3.25 :

"... is inserted after the second 23:59:59Z and before 24:00:00Z ..."?
"... omission of the second 23:59:59Z." - that day presumably ends at
the instant 23:25:59Z rather than the usual 24:00:00Z.

CHECK THAT>!!!



(H) : Section 3.30 :

One revolution around the Sun can only mean with respect to the "Fixed
Stars". But, if I recall correctly, the Calendar year is designed to be
locked to the Seasons. The Seasons are controlled by the relationship
between the Earth's axis of rotation and the Earth-Sun line; it is
Summer when our end of the axis points most nearly towards the Sun. But
the Earth's axis moves with respect to the Fixed Stars; I think it
circles the orbital axis with a period of about 26000 years. If that
is the case, the Section must be wrong.

Use something like "cyclic time interval of the seasons" in a calendar
(approximated ... days)"?



(I) : Section 4.3.2.1, paragraph 2 :

ISO 8601:2000 does not fix the position of the Gregorian Calendar scale
exactly against the scale of actual physical days.

I've read, in reference to ISO 8601:2004, "The point of reference for
the Gregorian calendar and ISO 8601 is 1875-05-20, the date of the
signing of the «Convention du Mètre» in Paris".

If ISO 8601:2004 gives that exact date, then they have addressed one of
the points I would have made ... but in a less than satisfactory manner.

The signing of the Convention on 1875-05-20 is not a reproducible event;
the only way in which we can now tell which day it was signed is by
reference to a scale of dates, such as JDN, CJD, or Gregorian - a
circular argument.

ISO 8601:2000 only said that the signing was in 1875, leaving the scale
loosely attached to an event no longer observable.  A definite
attachment to such an event is only a partial cure.


I feel that it would be much better to fix the scale by reference to an
astronomical event such as the Solar Eclipse of 1999-08-11 Wed.

Being a Solar Eclipse, it was of necessity observable only in the
daytime; it was observable, as total or partial, by an unusually large
number of people, countries, observatories, and other relevant
establishments - including BIPM and UN/ECE - and crossed the Greenwich
Meridian.

For millennia to come, at least until we start adjusting our part of
the Solar System, it will be possible to determine from then-current
observations precisely how many days ago that Eclipse was; and to
distinguish it from other Eclipses by its season and track.  It would,
if necessary, enable the Calendar positioning to be recovered.



(J) : Section 4.3.2.1, Notes 1, 2 :

Word "prolaptic" should be "proleptic".



(K) : Section 4.3.2.2, paragraph 2 :

"The reference point of the week calendar assigns Saturday to 2000
January 1" - which properly fixes the days of the week against the scale
of Gregorian dates.

But I suggest that it would be more elegant to use instead "The
reference point of the week calendar assigns Monday to 2001 January 1",
since Monday is the start of the defined Week and 2001-01-01 is the
start of a Millennium by Anno Domini dating.  In fact, 0001-01-01 would
also be suitable.



(L) : Section 4.3.2.2, paragraph 3 :

"... the first calendar week of a year is the one which includes the
first Thursday of that year ..." - clear enough.

But I suggest that it could more elegantly be defined by saying that any
week which has a majority of its days in a Gregorian Calendar year is
numbered as belonging to that year number. The notes following would
then be adjusted.

The suggested definition seems better because it addresses the situation
in terms which are more general, and so more readily adapted to apply to
any analogous situations which may be discovered. It is fully equivalent
to that in ISO 8601:2000.



(M) : Section 5 :

This section contains many instances of the number 30, referring to
seconds or minutes. But the Standard also contains instances of 30
referring to the number of days in some months. To ease electronic
searching, I suggest that the minutes examples be changed to 45 and the
seconds ones to 55 - neither of those numbers are used in ISO 8601:2000.

Likewise, there are date examples using 12 for day-of-month (ref sec
5.2); I suggest changing to 26 here - it is not otherwise used (except
as a page number) and moreover it cannot be misinterpreted as being a
month number.

Keep the year in the late 1900s, for similar reasons.



(N) : Section 5.2.2 :

Possibly insert "calendar" in "any year", to eliminate any possibility
of it being used for the "week-numbering year" of exactly 52 or 53
weeks.  Cf. 5.2.2.1.



(O) : Section 5.3.4.2 para 2 :

Since Summer Time is longer than Winter Time, "normally" is perhaps not
the best way of expressing what is meant, especially as the standard
date is April 12, which is in Summer Time.



(P) : Section 5.4.1, Note :

Surely the T is not omitted but replaced by a space?



(Q) : Section 5.5.3.2 :

Does that imply that all "carry-over points" can be, although not
exceeded, reached? I see a need to use months of 30 days, but not to
use 24 hours or 60 minutes.


				--------


Added, 2005-03-30 -
 
An article at http://en.wikipedia.org/wiki/ISO_8601, dated 2005-01-01,
implies that (I) above still applies.

For UTC, one can put Z after the time. It should be explicitly
permissible to put Z after a timeless date, to indicate that it is a UTC
date as opposed, day, to Australian or Hawaiian.

Wiki implies that (P) above is dealt with.


				--------


Added, 2005-05-21 -
 
Section 4.3.2.2 -

The sentence "A calendar week is identified within a calendar year by
the calendar week number." does not fit well with the fact that a
Gregorian year such as 2001 has days of a Week 1 at both ends, and a
Gregorian year such as 2006 has days of a Week 52 at both ends. 

				--------

Added, 2005-07-21 -

Time interval : duration :-

It seems unclear as to whether a duration of one month is to the same
date in the next month - in which case what happens if that month does
not contain that date - or is a fixed 30 days, or must be settled by
agreement or specific fiat.

It also seems unclear as to what is done about Summer Time, which makes
a year have a day of 23 hours and another of 25 hours.

There may be a need to be able to specify a duration as a number of
units greater than the normal maximum ; e.g. 86400 seconds, 99 weeks,
etc.

Is there a need for anything to be put about repetitive intervals?

				--------



*** ADDED 2007-02-10 : I now have a copy of ISO 8601:2004 and intend
to update this page soon.
*** ADDED 2008-09-19 : No, a new page u-8601-3.txt

2008-01-23 : add : a string form to represent not LCT and offset but
UTC and offset.


		   -------------- END --------------