Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0001639 [Issue 8 drafts] Base Definitions and Headers Objection Clarification Requested 2023-03-05 06:57 2024-06-11 09:12
Reporter kre View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed   Product Version Draft 2.1
Name Robert Elz
Organization
User Reference
Section XBD 8.3 TZ
Page Number 162
Line Number 5643-5644
Final Accepted Text Note: 0006205
Summary 0001639: Clarify minimun length requirement of "quoted" std and dst names in POSIX TZ string.
Description In the description of the POSIX TZ string, in the XBD 8.3 section that
describes the TZ variable, it says:

std and dst Indicate no less than three, nor more than {TZNAME_MAX},
                  bytes that are the designation for the standard (std)

and that's fine, then in the description of the quoted form encoding
of those fields, we have:

Each of these fields may occur in either of two formats quoted or
unquoted:

     -- In the quoted form, the first character shall be the <less-
        than-sign> ('<') character and the last character shall be
        the <greater-than-sign> ('>') character.

That's fine too.

Then the description (after text about the allowed chars, not relevant
here) it concludes:

        The std and dst fields in this case shall not include the
        quoting characters.

And that is OK too, so if we had
        TZ='<+0700>-7'
that would be OK, and the tzname for standard time would be +0700
(with an offset 7 hours ahead of UTC) with the '<' and '>' chars
not included (and no summer time applies).

That's all fairly straight forward.

However, it turns out there is an ambiguity there (or at least it
seems like there is).

The way I read this, is that the std (and dst if given) fields must
be 3 bytes long (at least - forget the max for now), and those 3
bytes can include the '<' and '>' chars, which would make

        TZ='<Z>0'

also acceptable. That is, I read the sentence:

        The std and dst fields in this case shall not include the
        quoting characters.

as meaning that the names extracted from the std and dst fields
don't include the quote characters (and for convenience they're
still called "std" and "dst" as the rest of the text refers to
them that way) - the "minimum 3 bytes" test has already been
satisfied.

Others apparently read that as if it said "when quoted, the minimum
length of the field is 5 bytes, including the quotes, leaving at
least 3 bytes for the extracted name."

It was even claimed that POSIX requires tzname (timezone name
abbreviations -- no-one has ever invented a good term to use to
refer to these things) fields to be at least 3 chars (bytes) long,
because of this rule.

But that's clearly not the case, as in the ':' form (or in the
new "geographic/special" form added by 0001619 there is no
such requirement, it is all implementation defined. Nothing I
can find elsewhere (which doesn't mean it doesn't exist) places
any limits (minimum, maximum, or allowed characters) upon those
values, the limits are there only for the sake of parsing the
POSIX TZ string.

Note that if I am incorrect, and the intent really was to require
at least 3 bytes between the '<' '>' quoting characters, then
first, why? And second that must mean that, assuming
TZNAME_MAX=10 (no idea if it is allowed to be or not, I am picking
10 because strlen("TZNAME_MAX") == 10, then
        TZ='<TZNAME-MAX>12'
would be a legitimate TZ string, where here there are 12 chars
(that is, more than TZNAME_MAX) in the "std" field as it first
appears. [Aside: the change in the example from '_' to '-' was
deliberate, '-' is an allowed character there, '_' probably is
not].

Note the "Why?" there is not rhetorical, an implementation can
choose to accept
        TZ=':<Z>0'
as a legitimate TZ string (because of the ':' the format is
implementation defined) producing a one character tzname (abbreviation),
in this particular case, it isn't even an odd thing to want to do.
That is, applications need to deal with short tzname (tm_zone) values
anyway, restricting the normal quoted format to prevent it seems kind
of petty.

The unquoted form I understand, that has been around since the
dark ages, and 3 char (3 byte) abbreviations were what it initially
allowed - altering that would be hard. The quoted form is much
newer (and far less commonly used).
Desired Action Change the sentence in XBD 8.3 TZ variable description,
on page 162 of I8 D2.1, lines 5643-4, from:

The std and dst fields in this case
shall not include the quoting characters.

to be:
The tzname abbreviations obtained from the std
and dst fields in this case shall not include the
quoting characters, but shall be referred to as the std
or dst fields, as appropriate, throughout the remainder
of this specification, the requirement that the fields be at
least 3 bytes long applies to the quoted form, the minimum length
after the quoting characters have been removed is 1 byte.


There is no need to say anything about the maximum length of
the quoted fields, as removing the '<' and '>' cannot make
them become longer, only shorter.

If this is not to be the intent of the standard (again, why?)
then after the sentence quoted above (lines 5643-4 on page 162
of I8 D2.1) add a new sentence.

Note: In this case, the quoted std, and
dst (if present) fields shall have a minimum length
of 5 bytes, and a maximum length of {TZNAME_MAX}+2 bytes.


But why?
Tags applied_after_i8d3, tc3-2008
Attached Files

- Relationships
related to 0001638Closed Requirement that TZ "std" and "dst" be 3 chars long (when given) is apparently ambiguous 

-  Notes
(0006189)
kre (reporter)
2023-03-05 07:01
edited on: 2023-03-05 07:03

 In the above Desired action, I somehow managed to enter < em >
where I meant to put < /blockquote >

The spell checker did not catch that (yes, I used one this time!)
(0006190)
Don Cragun (manager)
2023-03-05 07:44

 The mismatched < em > has been replaced by < /blockquote >. The matched < em > < /em > pairs have been replaced by the more common < i > < /i > pairs.
(0006191)
eggert (reporter)
2023-03-05 10:15

 As I noted in the tz mailing list (see the second half of <https://mm.icann.org/pipermail/tz/2023-March/032629.html>), [^] current GNU/Linux, macOS, AIX, and Solaris all require at least three bytes in 'std' and 'dst' (not counting the quoting characters) for proper results, and requiring support for TZ='<Z>0' would invalidate the current implementation of these systems.

Assuming the idea is to standardize existing practice, POSIX should simply require at least three bytes in 'std' and 'dst', not counting any quoting characters. That way, existing systems would continue to conform.

The main argument for invaliding existing implementations is the possibility that the US Congress might require "permanent DST", and that the common abbreviation for US Eastern time might become "ET" (instead of "EST" or "EDT" each of which would become confusing). If we're concerned that this needs to be addressed in POSIX now just in case, then the minimum lengths for 'std' and 'dst' should indeed be shrunk to 2 bytes (or to 1 byte; why stop at 2?). However, if such a change is made the minimum length should be computed after quoting chars are removed, so that (for example) TZ='ET4' should act like TZ='<ET>4' for the hypothetical Eastern Time.
(0006205)
geoffclare (manager)
2023-03-16 15:39

 Change:
The std and dst fields in this case shall not include the quoting characters.
to:
The std and dst fields in this case shall not include the quoting characters and the quoting characters do not contribute to the three byte minimum length and {TZNAME_MAX} maximum length.

- Issue History
Date Modified Username Field Change
2023-03-05 06:57 kre New Issue
2023-03-05 06:57 kre Name => Robert Elz
2023-03-05 06:57 kre Section => XBD 8.3 TZ
2023-03-05 06:57 kre Page Number => 162
2023-03-05 06:57 kre Line Number => 5643-5644
2023-03-05 07:01 kre Note Added: 0006189
2023-03-05 07:03 kre Note Edited: 0006189
2023-03-05 07:03 kre Note Edited: 0006189
2023-03-05 07:44 Don Cragun Note Added: 0006190
2023-03-05 07:44 Don Cragun Desired Action Updated
2023-03-05 10:15 eggert Note Added: 0006191
2023-03-16 15:39 geoffclare Note Added: 0006205
2023-03-16 15:40 geoffclare Final Accepted Text => Note: 0006205
2023-03-16 15:40 geoffclare Status New => Resolved
2023-03-16 15:40 geoffclare Resolution Open => Accepted As Marked
2023-03-16 15:41 geoffclare Tag Attached: tc3-2008
2023-03-16 15:48 geoffclare Relationship added related to 0001638
2023-05-16 11:07 geoffclare Status Resolved => Applied
2023-05-16 11:07 geoffclare Tag Attached: applied_after_i8d3
2024-06-11 09:12 agadmin Status Applied => Closed

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker