185Re: [ISO8601] Re: Clarifications: 220.127.116.11
- Jul 14 12:04 AMg1smd@... wrote:
> Section 4.6 refers. 'These leading hyphens may be omitted inThis is probably why the note which looks unobvious to me is
> the applications where there is no risk of confusing these
> representations with others'. Any leading hyphen would always
> be to replace a missing element. Hyphens between elements are
> separators in Extended Formats. There are no separators in the
> Basic formats. There are never any separators before the first
> element, only 'replacement' hyphens for missing elements.
obvious to you. I read 4.6 with the most important opening
phrase "By mutual agreement of the partners in information interchange"
Thus, it provides a way in specific applications of this standard to drop
something this is stated in the standard. I don't see 4.6 as suggesting that it
is the rationale which was used to come up with the formats which are in standard.
> It's all inIt says you can drop what is there, but it doesn't say that the full representation
> paragraph 4.6 as far as I can see.
would treat the hundreds part of the year as a separate component from
the tens and ones of the year. Only a few examples hint at that, but not
all of them do and not all exceptions are noted.
> Does this still appearI wouldn't know, I don't have it, I just have the various free downloads.
> in the published ISO 8601:2000?
Hopefully this was clear. If not it should be by now.
> > -YY appears in truncated calendar dates, i.e. -YY-MM-DD,Sorry, my mistake. It should have read "-YY-MM".
> > see examples of section 18.104.22.168.
> You have misquoted the standard.
> In all these formats: -YYMM and -YY-MM, and -YY, the hyphenAgain, that is not what a pedantic read of 4.6 says. 4.6 says me and
> does replace the missing two digits of the 'century'. In
> YY-MM-DD it has been left out, as per para 4.6.
who ever I communicate with can cut what we see even further when we are
only using some agreed upon subset of everything, it doesn't
provide a rationale for what is in the standard.
> > 22.214.171.124 (a) YY-DDD <-- no dash for missing numeric centuryIt is too bad that 4.6 doesn't actually introduce the idea that
> Yes, because in 05-005, the '005' has to be the Day of the Year,
> there is absolutely no other possibility. Therefore, the element
> before that has to be a two-digit year. The leading hyphen can
> therefore be omitted, exactly as per the YY-MM-DD example, above.
> That is, -YY-DDD is unecessary, YY-DDD will suffice.
the writers of the standard used the idea as you
claim, to come up with their various formats.
Maybe, some discussion at 5.2.1 ... Year would actually set at least
me in the right mind set.
Also, if your suggestion as to the design is the case, I would expect a note
like the one I was surprised to see in 126.96.36.199 after 188.8.131.52 (a)
and the note at 184.108.40.206 noting all of the variations which are
not "fully hyphenated". This would make them all consistent.
The note at 220.127.116.11 would not list only
one format, but mention all of those which one might think might have
a leading dash for missing 'century' and another for missing year pointing
out the simplification.
In fact, the standard before the first truncated format in the opening paragraph
of 18.104.22.168 says "In each case hyphens that indicate components should be used only
as indicated or shall be omitted."
That to me hints that some of choices are arbitrary, so don't play around with
them. Also, there is no place that states that all formats are mutually
unambiguous from each other. As I was reading I was looking for just such
a statement or examples that violated the idea. I found neither, but that
is no proof.
Hopefully this can all be clarified in the next edition.
> OVER TO YOU! There are over 100 people out there reading this.The question is not whether you are right, it is a question of
> What say all of you? Am I right? Dan Kohn? Fred Bone? Pete
> Forman? Aron Roberts?
meaning of the standard. Or another way to put it: You may be right,
and I have no reason to think you aren't, but the standard is still
not clear on where the "should" comes from.
I personally am now convinced by what you have provided that
I was misled by the facts that the very first truncated example
YYMMDD doesn't have a leading dash, doesn't have a note which
points this out and there is nothing up to that point which says
what the expected style is, and there is no consistency in the following
examples, so when I finally get to 22.214.171.124 "note: ... should be ..."
I go back and read looking for something that tells me what should
be anywhere and all I see are various examples without explanation
that any are exceptions to any expectations. Thus reading the
standard does not make me think there is any "should" involved other
than the examples as given. That is the source of my question
about this note.
> You actually said:Gee, this is a useful comment, who wasn't going to discuss each
> >>>> Also, were to where or whom do I send simple typo corrections?
word and comma? :-(
> > Anyone know the USA rep, or the list of IEEE committee members?Yes of course it should, (not that there is an ISO standard defining that
> The ANSI or NIST Web Sites should direct you to that information.
it should! :-) I already tried that and didn't find it.
> Try that one as well. What is there to lose? If they can'tAny suggestion in my opinion is probably better than just
> help you then I would hope they would point you towards someone
> who can. Maybe one of the 100-plus people receiving this email
> has a better suggestion?
pointing out that there are some e-mail addresses. I was actually
hoping for something useful not just the obvious. I have noted
your comments with regard to Louis Visser.
- << Previous post in topic Next post in topic >>