Subject: [Tzdist-bis] standard wall indicators and UTC/local indicators

From: Eliot Lear <[email-masked]>
Date: Mon, 28 May 2018 11:14:47 +0200

Hi,

In reading the draft, I think there's at least ambiguity on two aspects
of how to use standard wall indicators and UTC/local indicators.  There
are two key issues:

 1. The text is a bit unclear as to how to index to the right value of
    std/wall or utc/local.  I read them as tied to the transition time
    index, but (a) I could be wrong and (b) we should be explicit. 
    Similarly, in what circumstances would it be true where typecnt,
    isdstcnt, and isutccnt would differ?
 2. We should be a bit more clear about how std/wall and utc/local are
    used.  Specifically, what if the UTC/local indicator is set to 1? 
    Should one have any reason to reference std/wall?

Eliot

---

From: Paul Eggert <[email-masked]>
Date: Mon, 28 May 2018 15:43:43 -0700

>     isdstcnt, and isutccnt would differ?

Applications use the type field to index those two tables. isutccnt must 
always be either zero, or equal to typecnt. Similarly for isstdcnt. When 
these two values are zero, it is as if the corresponding array of flags 
contain only zeros. Of course we should put all this into the spec.

>  1. We should be a bit more clear about how std/wall and utc/local are

The only reason to use either field is if the user has specified a TZ 
value like "AKST9AKDT" that (1) is not the name of a TZif file, and (2) 
is a POSIX TZ setting that asks for DST but does not specify when the 
DST transitions are. When this happens, an application is expected to 
transform the transitions of an implementation-specific TZif file 
(America/New_York, say) into transitions appropriate for the requested 
TZ setting. To do this, the app needs to know whether the New York 
transitions were the result of rules that specified UTC (as EU rules do) 
or local  time (as US rules do) or standard time (as New Zealand rules 
do). The two bits of the two flags in question provide enough 
information to tell applications which of the three possibilities apply. 
(There are three possibilities not four; if the utc flag is set the std 
flag must also be set; no doubt the TZif spec should say that too.)

---

From: Ken Murchison <[email-masked]>
Date: Tue, 29 May 2018 12:06:37 -0400

On 05/28/2018 06:43 PM, Paul Eggert wrote:
>>  1. The text is a bit unclear as to how to index to the right value
>>     of std/wall or utc/local.  I read them as tied to the transition
>>     time index, but (a) I could be wrong and (b) we should be
>>     explicit.  Similarly, in what circumstances would it be true
>>     where typecnt, isdstcnt, and isutccnt would differ?
>>
>
> Applications use the type field to index those two tables. isutccnt 
> must always be either zero, or equal to typecnt. Similarly for 
> isstdcnt. When these two values are zero, it is as if the 
> corresponding array of flags contain only zeros. Of course we should 
> put all this into the spec.

I added the following text to the descriptions of isutccnt and isstdcnt:

" - MUST either be zero or equal to 'typecnt'."

I added the following text to the descriptions of standard/wall and 
UTC/local respectively:

"If 'isstdcnt' is zero (0), all transition times associated with local 
time types are assumed to be specified as wall time."

"If 'isutccnt' is zero (0), all transition times associated with local 
time types are assumed to be specified as local time."

>>  1. We should be a bit more clear about how std/wall and utc/local
>>     are used.  Specifically, what if the UTC/local indicator is set
>>     to 1?  Should one have any reason to reference std/wall?
>>
>
> value like "AKST9AKDT" that (1) is not the name of a TZif file, and 
> (2) is a POSIX TZ setting that asks for DST but does not specify when 
> the DST transitions are. When this happens, an application is expected 
> to transform the transitions of an implementation-specific TZif file 
> transitions were the result of rules that specified UTC (as EU rules 
> do) or local  time (as US rules do) or standard time (as New Zealand 
> rules do). The two bits of the two flags in question provide enough 
> information to tell applications which of the three possibilities 
> apply. (There are three possibilities not four; if the utc flag is set 
> the std flag must also be set; no doubt the TZif spec should say that 
> too.)

I added the following text to the description of UTC/local value=1:

", and the corresponding standard/wall indicator MUST also be set to one 
(1)."

Do you have suggested text for handling of TZ variable?  Of is 
how/when/why apps use these values outside of the scope of TZif?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Paul Eggert <[email-masked]>
Date: Tue, 29 May 2018 14:53:28 -0700

> how/when/why apps use these values outside of the scope of TZif?

I'm afraid that the text I wrote is about the best I can do offhand. 
Although it's not a formal definition the flags' meaning, perhaps it 
could be used as an example of how a client might use the flags.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 30 May 2018 18:41:11 -0400

> the std flag must also be set; no doubt the TZif spec should say that 

So, in your example America/New_York is being used as a template for 
determining Alaskan transitions?  Is this a POSIX TZ string thing only, 
or are there other uses of "reconstructing tzdb rules"?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Paul Eggert <[email-masked]>
Date: Wed, 30 May 2018 16:53:59 -0700

On 05/30/2018 03:41 PM, Ken Murchison wrote:
> determining Alaskan transitions?

Yes. Any incomplete TZ string will use America/New_York DST rules, if 
America/New_York is the default (which it is in the standard tzdb; see 
the POSIXRULES macro in the Makefile). In practice the default is 
usually America/New_York and this approach works works only for North 
American time zones. This is a bit better than the traditional behavior 
where the then-current US DST rules were hardwired into the code, as it 
(a) moves the default behavior from code to sysadmin-specified data and 
(b) handles older US timestamps correctly even if the US changes its DST 
rules.

> Is this a POSIX TZ string thing only, or are there other uses of 
> "reconstructing tzdb rules"?

I don't know of any other uses. As far as I know, these data entries are 
used only for filling out incompletely-specified POSIX TZ strings. At 
least, that's all that they're used for in tzcode and in glibc (I just 
checked).