Subject: [Tzdist] TZUNTIL question

From: Ken Murchison <[email-masked]>
Date: Wed, 10 Sep 2014 15:56:55 -0400

All,

draft-ietf-tzdist-service-01 adds a new TZUNTIL iCalendar property to be 
used when the server truncates the "tail" of a time zone (e.g. when 
America/New_York is truncated at 20191231T235959Z).

Should the same property be used in an "untruncated" VTIMEZONE object if 
the timezone itself seems to have a finite end?  For instance, for the 
zone below, should the VTIMEZONE derived from these rules contain 
TZUNTIL=20081026T010000Z ?  Or does this zone continue with a constant 
UTC offset into eternity?  If the latter, does the IANA tzdata have a 
way of distinguishing between finite and infinite time zones?

# Rule    NAME    FROM    TO    TYPE    IN    ON    AT    SAVE LETTER/S
Rule    Tunisia    1939    only    -    Apr    15    23:00s 1:00    S
Rule    Tunisia    1939    only    -    Nov    18    23:00s    0 -
Rule    Tunisia    1940    only    -    Feb    25    23:00s 1:00    S
Rule    Tunisia    1941    only    -    Oct     6     0:00    0    -
Rule    Tunisia    1942    only    -    Mar     9     0:00 1:00    S
Rule    Tunisia    1942    only    -    Nov     2     3:00    0    -
Rule    Tunisia    1943    only    -    Mar    29     2:00 1:00    S
Rule    Tunisia    1943    only    -    Apr    17     2:00    0    -
Rule    Tunisia    1943    only    -    Apr    25     2:00 1:00    S
Rule    Tunisia    1943    only    -    Oct     4     2:00    0    -
Rule    Tunisia    1944    1945    -    Apr    Mon>=1     2:00 1:00    S
Rule    Tunisia    1944    only    -    Oct     8     0:00    0    -
Rule    Tunisia    1945    only    -    Sep    16     0:00    0    -
Rule    Tunisia    1977    only    -    Apr    30     0:00s 1:00    S
Rule    Tunisia    1977    only    -    Sep    24     0:00s    0 -
Rule    Tunisia    1978    only    -    May     1     0:00s 1:00    S
Rule    Tunisia    1978    only    -    Oct     1     0:00s    0 -
Rule    Tunisia    1988    only    -    Jun     1     0:00s 1:00    S
Rule    Tunisia    1988    1990    -    Sep    lastSun     0:00s 0    -
Rule    Tunisia    1989    only    -    Mar    26     0:00s 1:00    S
Rule    Tunisia    1990    only    -    May     1     0:00s 1:00    S
Rule    Tunisia    2005    only    -    May     1     0:00s 1:00    S
Rule    Tunisia    2005    only    -    Sep    30     1:00s    0 -
Rule    Tunisia    2006    2008    -    Mar    lastSun     2:00s 1:00    S
Rule    Tunisia    2006    2008    -    Oct    lastSun     2:00s 0    -

# Zone    NAME        GMTOFF    RULES    FORMAT    [UNTIL]
Zone    Africa/Tunis    0:40:44 -    LMT    1881 May 12
             0:09:21    -    PMT    1911 Mar 11 # Paris Mean Time
             1:00    Tunisia    CE%sT

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Tim Parenti <[email-masked]>
Date: Wed, 10 Sep 2014 16:09:47 -0400

On 10 September 2014 15:56, Ken Murchison <[email-masked]> wrote:

> does the IANA tzdata have a way of distinguishing between finite and
> infinite time zones?

To my knowledge, it does not.  As far as I know, it currently aims to be
accurate at least through the end of signed-32-bit time in early 2038.
Some cases like America/New_York are easily extendable beyond that.  Others
like Africa/Cairo are not.

Africa/Tunis is an interesting example of a zone which used rules in the
past, but does not currently, and has no future rules listed.  From a tz
perspective, I would think the idea is that a constant offset is to be
applied from the last rule through at least 2038, in the absence of later
updates which may supersede that.

I think it would be rather silly to have TZUNTIL=20081026T010000Z for this
zone, since clearly it has a valid and well-defined meaning well beyond
that point.

As we inch closer to the signed-32-bit horizon, tz should probably grapple
with these concerns about which zones "extend into infinity" and which
don't.  There would be many valid approaches for this.  In the meantime,
should tzdist prescribe some sort of behavior here?

--
Tim Parenti

---

From: Ken Murchison <[email-masked]>
Date: Wed, 10 Sep 2014 16:13:37 -0400

Thanks Tim.

So is it your opinion that any VTIMEZONE derived directly from the IANA 
tzdata (and not subsequently truncated) would NOT contain TZUNTIL?

On 09/10/2014 04:09 PM, Tim Parenti wrote:
>
> On 10 September 2014 15:56, Ken Murchison <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     does the IANA tzdata have a way of distinguishing between finite
>     and infinite time zones?
>
>
> To my knowledge, it does not.  As far as I know, it currently aims to 
> be accurate at least through the end of signed-32-bit time in early 
> 2038.  Some cases like America/New_York are easily extendable beyond 
> that.  Others like Africa/Cairo are not.
>
> Africa/Tunis is an interesting example of a zone which used rules in 
> the past, but does not currently, and has no future rules listed.  
> From a tz perspective, I would think the idea is that a constant 
> offset is to be applied from the last rule through at least 2038, in 
> the absence of later updates which may supersede that.
>
> I think it would be rather silly to have TZUNTIL=20081026T010000Z for 
> this zone, since clearly it has a valid and well-defined meaning well 
> beyond that point.
>
> As we inch closer to the signed-32-bit horizon, tz should probably 
> grapple with these concerns about which zones "extend into infinity" 
> and which don't.  There would be many valid approaches for this.  In 
> the meantime, should tzdist prescribe some sort of behavior here?
>
> --
> Tim Parenti

---

From: Tim Parenti <[email-masked]>
Date: Wed, 10 Sep 2014 16:24:18 -0400

> tzdata (and not subsequently truncated) would NOT contain TZUNTIL?

Not quite; it is my opinion that, given the stated scope of IANA tzdata as
it stands currently, TZUNTIL=20380119T031407Z by default.

tz currently makes no special effort to extend data beyond this point,
although many zones are simple enough that it is able to do so anyway
(through use of "max").  Perhaps those zones with a "max rule" would have
no TZUNTIL, indicating that they are able to be extended to
positive-infinity.  That seems a bit kludgy, though, as deriving such
semantic meaning from tz could overload the intent behind "max" if not done
with careful review of the relevant data.

Ultimately, a lot of work on extending beyond 2038 is on the horizon, so
future formats should explicitly indicate this in some way, but that's
outside our scope here.

This is all just my opinion, in the truest sense of the word.  I'm sure
others will chime in in due course.  ;)

--
Tim Parenti

---

From: Paul Eggert <[email-masked]>
Date: Wed, 10 Sep 2014 13:47:08 -0700

On 09/10/2014 12:56 PM, Ken Murchison wrote:
> does this zone continue with a constant UTC offset into eternity?

Yes.

> If the latter, does the IANA tzdata have a way of distinguishing 
> between finite and infinite time zones? 

There's no formal distinction in the tz data, unfortunately; it's 
covered by the comments only.

TZUNTIL should typically be omitted for all data derived from the tz 
database.  This is because clients should see the identical timestamps 
regardless of whether they get it from tzdist or via conventional means, 
and this should include even time stamps in weird cases such as 
Africa/Cairo in the year 2100.

However, if the server imposes its own limitations before the end of the 
year 9999, TZUNTIL should list the last second that the server actually 
supports.  For example, a server that uses 32-bit POSIX time_t for its 
calculations should specify a TZUNTIL value of 20380119T031407Z.  I 
don't recommend servers like that, though; servers should normally use 
64-bit time_t, because so many clients are 64-bit nowadays.

-----

Here are some more details about the tz mechanics, if you're interested.

Generally speaking, the tz database currently simplifies rules around 
the year 2038 if the format can't represent them into the indefinite 
future.  This doesn't necessarily mean that there are no transitions 
after 2038; all it means is that the post-2038 transitionsdon't match 
our best prediction of how clocks are planned behave.  Cases when this 
occurs are noted in the comments.

For example, Africa/Casablanca's rules go past 2038 but are less 
detailed and more likely to be wrong for years past 2038.  Here, the 
calendar cannot be predicted accurately in advance even in theory, so 
there's some justification for punting with an approximation.

A more amusing example is America/Sao_Paulo, where the post-2038 
predictions are most likely wrong for years when Carnival Sunday is the 
third Sunday in February.  The Carnival constraint is so obscure -- it's 
based on the Gregorian computus -- that it's not supported by the tz 
database, and I expect even VTIMEZONE can't represent the constraint 
even though it's purely computational.

As Tim Parenti mentioned, we'll need to do better on this frontwell 
before 32-bit time_t's roll around.The problem has been mentioned 
several times on the tz list but nobody has done anything about it yet.