View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001638Issue 8 draftsBase Definitions and Headerspublic2023-03-03 10:032024-06-11 09:12
Reporterkre Assigned To 
PrioritynormalSeverityObjectionTypeClarification Requested
Status ClosedResolutionAccepted As Marked 
Product VersionDraft 2.1 
NameRobert Elz
Organization
User Reference
SectionXBD 8.3
Page Number162
Line Number5648-5651
Final Accepted TextSee 0001638:0006204.
Summary0001638: Requirement that TZ "std" and "dst" be 3 chars long (when given) is apparently ambiguous
DescriptionThis could be filed against 7 TC2, and I think probably D3 (when it
appears as well) - I don't think the text has changed.

It wasn't changed by 0001619 though perhaps should have been.

The current (as in D2.1) text says:

   The interpretation of these fields is unspecified if either field is
   less than three bytes (except for the case when dst is missing),

To me that was always clear enough, it means that "dst" doesn't have to be
at least 3 chars, if it was omitted, that would be absurd. But on a (unrelated) mailing list, I have just seen a claim:

   When /dst/ is missing, /std/ can be less than 3 bytes.

which is obviously based upon reading that "except" as applying to both
"std" and "dst" rather than just "dst" which I have always assumed.

And when the text is read, without already having a preconceived idea of
what it is intended to mean, I can see how that interpretation is possible.

Beyond that, for all parts of the POSIX TZ strip specification, now that
0001619 has been applied, we really need to remove all "is unspecified"
in invalid cases - those should now be simply invalidating the string as
being considered as a POSIX TZ string, leaving it open to be considered as
one of the new form added by 0001619.

That part I am not going to supply new text for here, that can wait until
after D3 is available, when we know what we're working with.
Desired ActionReplace the paragraph in lines 5648-5651 (D2.1) on page 162

The interpretation of these fields is unspecified if either
field is less than three bytes (except for the case when dst is missing),
more than {TZNAME_MAX} bytes, or if they contain characters
other than those specified.


with (something like - and here I am making the working, for just this one
case for now, invalidate the string, as being a POSIX TZ string):

If std contains less than 3 bytes, or dst
(if present in the string) contains less than 3 bytes, or if either
std or dst contain more than {TZNAME_MAX} bytes, or
if either of those fields contains any characters other than those
specified, the string will not be a valid string of this format, and
shall be considered as a candidate for being of the third format.


(Yes, I know, that's ugly - someone else can do better...)
Tagsapplied_after_i8d3, tc3-2008

Relationships

related to 0001619 Closed Add support for TZ=Area/Location 
related to 0001639 Closed Clarify minimun length requirement of "quoted" std and dst names in POSIX TZ string. 

Activities

kre

2023-03-03 10:11

reporter   bugnote:0006187

Rather than "not be a valid string of this format, and
shall be considered as a candidate for being of the third format."
maybe it could say something like

"shall be a failure to match the syntax of this format" which then
fits with the text added in 0001619:0006073

Don Cragun

2023-03-03 14:31

manager   bugnote:0006188

Occurrences of "bugno:" and "POSIZ" in the Description have been changed to "bugid:" and "POSIX", respectively.

Don Cragun

2023-03-16 15:26

manager   bugnote:0006204

Change:
The interpretation of these fields is unspecified if either field is less than three bytes (except for the case when dst is missing), more than {TZNAME_MAX} bytes, or if they contain characters other than those specified.
to:
The interpretation of std and, if present, dst is unspecified if the field is less than three bytes or more than {TZNAME_MAX} bytes, or if it contains characters other than those specified.

Issue History

Date Modified Username Field Change
2023-03-03 10:03 kre New Issue
2023-03-03 10:03 kre Name => Robert Elz
2023-03-03 10:03 kre Section => XBD 8.3
2023-03-03 10:03 kre Page Number => 162
2023-03-03 10:03 kre Line Number => 5648-5651
2023-03-03 10:11 kre Note Added: 0006187
2023-03-03 14:31 Don Cragun Note Added: 0006188
2023-03-03 14:31 Don Cragun Description Updated
2023-03-16 15:12 nick Relationship added related to 0001619
2023-03-16 15:26 Don Cragun Note Added: 0006204
2023-03-16 15:26 Don Cragun Status New => Resolved
2023-03-16 15:26 Don Cragun Resolution Open => Accepted As Marked
2023-03-16 15:27 Don Cragun Final Accepted Text => See 0001638:0006204.
2023-03-16 15:28 Don Cragun Tag Attached: tc3-2008
2023-03-16 15:48 geoffclare Relationship added related to 0001639
2023-05-16 11:06 geoffclare Status Resolved => Applied
2023-05-16 11:06 geoffclare Tag Attached: applied_after_i8d3
2024-06-11 09:12 agadmin Status Applied => Closed