Emend ISO 8601:2004(E)

                             u-8601-3.txt 

    (c) J R Stockton    www.merlyn.demon.co.uk    >= 2011-12-05



I have a PDF copy of ISO 8601:2004(E). There are some points of varying
significance which I offer for consideration in drafting any later
version of the Standard; I have produced this page so that it may be
used in connection with the next update to ISO 8601.

There is at least one indisputable correction needed (in 3.2.2 Note 2).

In some cases the true meaning of a sentence in the Standard may be
obvious from reading it but not exactly stated by it.

(A previous version of this Web page, u-8601-2.txt, commented on ISO
8601:2000.)






Introduction : Paragraph 1

Different forms of date representation may be in use within the same
country, too; even in the same place. Contains "national boundaries" -
"national or regional" might be more complete. Paragraph 5 contains
"international boundaries".

It may be that, within the life of the Fourth Edition, it would be well
for it to refer to the representation of dates and times off-Earth.
Multinational work already occurs at the ISS; but new considerations
apply at distances where signal delay is appreciable.



Section 1

In the first three listed entries, "calendar year" has one meaning in
the first two and a somewhat different one in the third. A new term is
needed for "Year of 52 or 53 weeks each Monday to Sunday"; the term
would be used on other places in ISO 8601. The "week date" list line
should not need to include the word "calendar".

In the fifth entry : The choice between UTC and local can affect not
only time-of-day but also the date itself.  I suggest mentioning Date
here.

In paragraph 2 : "characters are not used" - I can only think of some
clocks with hands.



Section 2.1.3

NOTE : "limiting instants" - It would seem better if by default Time
could be divided into intervals such that every instant is in exactly
one interval. That requires that only one of the end instants is in the
Interval.



Section 2.1.4

NOTE 1 List 2 : But UTC has no discontinuities; it just has
variable-length minutes, like the Calendar has variable-length
Februarys. Affects 2.1.6 NOTE 1 wording. "Civil Time" is what is
affected by Summer/Winter discontinuities; "Standard Time"
conventionally refers to non-advanced Time. Also 2.1.6 NOTE 1.

NOTE 1 List 3 : Conflicts with 2.1.3 Note, in which an interval includes
both end-points.

NOTE 4 : Does the Standard actually define a reference _time_, or is the
positioning of date-changes considered obvious?



Section 2.1.7

NOTE : the duration of a civil day is not determined just by its
position in the calendar; Summer Time and Leap Seconds are non-Gregorian
influences.



Section 2.1.12

I wasn't aware that international atomic time was anything more than a
rate of seconds, without any specified zero.  And I have worked quite
near atomic clocks.

NOTE 3 : In practice, many systems are nominally locked to UTC but
smooth over Leap Seconds, so having 60 seconds on every minute. For
this, I think UT may be the correct term. For practical completeness,
should the term for what people think of as GMT (whichever it is) be
referred to here?



Section 2.1.14

Civil Time is affected by Summer/Winter; "Standard Time" conventionally
refers to non-advanced Time. The NOTE makes one think that Standard Time
is affected by Summer Time; I don't think that should be the intent.
Also 2.1.4 NOTE 1, 2.1.6 NOTE 1.

I suggest terms such as UTC, Local Standard Time, and Local Civil Time;
LST accommodates longitude, and LCT also accommodates season.



2.1.15 - "midnight" has not been defined. Also, it is frequently
considered as being 24:00 rather than 00:00.



Section 2.2.2

A leap second is not a time step. Time flows continuously at 1 Hz. The
effect of a leap second (like that of a leap day) is to give an unusual
numbering scheme in the representation of time..

NOTE - "called positive/negative" should be "called _a_
positive/negative".



Section 2.2.3 - equal to 59 or 61 seconds occasionally?



Section 2.2.5 - equal to 23, 23.5, 24.5 or 25 hours occasionally?



Section 2.2.6 :

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 01:00:00 - I think.  Would that be midnight?

NOTE 1 - "as _a_ day". 2.2.8, 2.2.11, 2.2.13 likewise.

Although the existing wording does encompass it, I suggest that there
should be a more specific reference to Summer (Daylight Saving) Time in
or near NOTE 2, because it is so easily forgotten. In the EU,
Switzerland, etc., the authorities deciding on Summer Time are not very
local.



Section 2.2.8 

NOTE 3 - The sentence "A calendar week may be identified by its ordinal 
number within its calendar year." 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. 

Perhaps there should, to reduce possible error in interpretation, be a
distinct term for a year starting with W01-1 and finishing just before
the next W01-1? Cf. comment on Section 1.



Section 2.2.9

NOTE - And, in the EU, just when does a week starting on Sun 2007-03-18
01:30:00 UK time or Sun 2007-10-21 01:30:00 UK time end? By the NOTE,
the first week has no end and the second week has two ends. Cf. 2.2.12
NOTE 1, 2.2.14 NOTE.



Section 2.2.10

A Week is not necessarily contained within a Calendar Year in the
Gregorian sense.

"... 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 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:2004.



Section 2.2.13 :

The phrase "one revolution of the Earth around the Sun" can only mean
with respect to the "Fixed Stars" - to the distant universe. 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, or at least inexact.

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

P.S. Note section 2.2.15.

NOTE 1 : as _a_ year.

NOTE 2 : A Gregorian Year is January 1st to December 31st inclusive. But
the term is often used in ISO 8601:2004 for the interval from the start
of a Week 1 Day 1 up to the start of the next Week 1 Day 1.



Section 2.2.18

"by _a_ hundred". A 2.2.19 could define "quadrennial". "Millennial"?



Section 3.2.1

In paragraph 2, the second sentence is falsified by the third.  Replace
". However," with ", except that" to avoid the infelicity.

And "Divisible by four an integral number of times" is nonsense. I can
divide 2008 by 4 as often as I like, and I always get 502. I can divide
2009 by 4 as often as I like; depending on the type of division, I get
502.25 or 502 1/4 or 502 remainder 1.  Use, for example, "year number
is an integer multiple of four" and likewise for 400.

ISO 8601:2000 did not fix the position of the Gregorian Calendar scale
exactly against the scale of actual physical days, though it give the
year number of a past event.

ISO 8601:2004 has "The Gregorian calendar has a reference point that
assigns 20 May 1875 to the calendar day that the "Convention du Mètre"
was signed in Paris" - why not write 1875-05-20 ? - which is an exact
positioning - and why not use it to fix the day of the week too?

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

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

Being a Solar Eclipse, it was of necessity observable only in the
daytime, and so on only one date; it was observable, as total or
partial, by an unusually large number of people, countries,
observatories, and other relevant establishments - including BIPM - and
crossed the Greenwich Meridian. A description of places and local mean
solar times of central totality will suffice to distinguish that Eclipse
from any other over a very wide interval of time.

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.



Section 3.2.2, paragraph 3 :

"The reference point of the time scale assigns Saturday to 1 January
2000" - which properly fixes the days of the week against the scale of
Gregorian dates (but it's not the point used earlier in the document).

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, proleptic
0001-01-01 would also be suitable.

NOTE 2 ! - contains [1996-31-12] which is BRF and should be [1996-12-31].
                                         (Barney Rubble Format)



Section 3.4.1 paragraph 2 :

Re "plus-minus" - Are there date representations with a "+-" character?
I think not.  The "+-" characters in this Standard surely represent
"either + or -" in the representation of a Date/Time; "+-" is not
interchanged.  If so, omit second sentence.
 


Section 3.4.1 end :

Re "space" - how about other whitespace, such as tab, new line, form
feed?
 


Section 4.1.1 :

There'd be something to be said for using, in examples, a day-of-month
greater than 13, so that it cannot possibly be confused with a month
number.



Section 4.1.2.4 :

That apparently requires the use of a leading + if the year is allowed
to exceed 9999, although Section 3.4.2 may allow it to be omitted. That
seems too strong. It seems to me that an application using only positive
years, and going past 9999, should be explicitly allowed to use no sign,
even if that is a change from what had been intended.



Section 4.2.1

If [24] is allowed to represent the end of a day, then perhaps [60]
could be allowed to represent the end of an hour, unless there are good
reasons otherwise. Etc.



Section 4.2.2.4, 4.2.4 ff. :

These sections contain 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 is used in ISO 8601:2004.

Likewise, there are date examples using 12 for day-of-month (ref sec
4.1.1); 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.



Section 4.2.2.5 :

Is the apparent restriction to "local" appropriate?



Section 4.2.4 :

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.



Section ? :

Where a date and time are associated, and the time is said to be in UTC,
then the date must also be a UTC date. That seems not to be everywhere
clearly expressed.

So, for example, Section B.1.2's first tables might be headed more like
"Combinations of local calendar date and time" and "Combinations of UTC
ordinal date and time".



Section 4.2.5.1 :

The Section is completely clear; but people often make mistakes of sign.
How about adding examples for Quito and Kampala, which are well known
to have different signs of longitude; being on the Equator, they need no
Summer time.  Granted, 4.2.5.2 has Geneva and New York.



Section 4.3.2, 4.4.5 :

The word "zone" is used to mean "offset from UTC", which commonly
changes with season. Dictionaries, etc., indicate that time zones do not
move seasonally.



Section 4.3.2 NOTE :

Surely the T is not to be omitted but is to be replaced by a space? Or
does the Standard consider 2003-05-05 06:07:03 as always two separate
entities?

Should there be something about how, if at all, date/times in text
may/should be split for line-wrap? One would expect that space-separated
date and time would be treated as two separate words, though a
non-breaking space could be used.  Internet Explorer will not break a
time, but it will break a date after a separator.

Unicode has a whole class of white-space characters, some of which have
no vertical effect. Obviously \u0020 is allowed. How about \u00A0; and
the others?

(POSSIBLY MISPLACED :) The Standard seems to have no mention of Unicode;
surely it should.  That has a no-break hyphen, \u2022 = ‑, which
appears well-suited to be a date separator, at least on a Web page.



Section 4.4.3 : Time interval : duration :-

It also seems unclear as to what is done about Summer Time, which makes
a year have a day of 23 [or 23.5] hours and another of [24.5 or] 25
hours. In practice, it might be necessary to stipulate a duration as
shown by the readings of either a local civil or a UTC clock.

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



Section 4.4.3.1 :

Leap Seconds mean that Hour and Minute do not have truly accurate
duration.



Section 4.4.3.3 :

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. Or should 30 read 31? Should "must not exceed"
read "must be less than"? No hour has 60 minutes. But then there seems
to be a set of durations between 12 months of 30 days and a year of at
least 365 days. Perhaps more explanation is needed.

It is safe to use weeks, with and without days etc., to express
duration, provided that there is no year component.



Section 4.5 :

I think "Recurring time interval" should be "Recurring contiguous time
intervals" - one can express the 24 recurring hours of a normal day, but
not the 7 recurring lunch hours of a week, let alone the 10 recurring
weekday lunch hours of a fortnight.



Annex A : List 1 : 

"... use differing systems of ascending order;" - other than order
day-month-year, what else can there be? The American month-day-year is
disorderly, neither consistently ascending nor descending.



Annex A : List 2 :

One might add "sorting" and/or "comparison", because of their practical
importance.


===


Possible Additions : There may be a need to do things fortnightly. One
cannot use the ISO Week Number alone for this, because of 53-week years.

We already have well-defined Day Numbers in Chronological Julian Date
and Modified Chronological Julian Date - they could easily be added to a
new Edition.

CJD 0 was a Monday, so Absolute Week Numbers (AWM) can nicely be defined
as Trunc(CJD div 7). CMJD 0 was a Wendesday, however. Odd-numbered
millennia always begin on a Monday, so Week 0 (or 1) could start on
0001-01-01 or 2001-01-01.

Fortnightly is thus just whether AWN is even or odd; four-weekly is
given by AWN mod 4, etc.

It seems not _absolutely_ clear in the standard, but evidently intended,
that, in a combination of date, time, offset, either all three must be
basic or all three must be extended. I have seen date & time extended
with offset basic.



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