Subject: [Tzdist] Ticket #11

From: Ken Murchison <[email-masked]>
Date: Wed, 27 Aug 2014 08:05:35 -0400

Paul's suggested text looks good to me.  If adopted, it looks like we 
need to add a new protocol element for advertising a future truncation year.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Ken Murchison <[email-masked]>
Date: Wed, 27 Aug 2014 08:06:24 -0400

Sorry,  had the wrong ticket number in the original post.

---

From: Lester Caine <[email-masked]>
Date: Wed, 27 Aug 2014 13:28:45 +0100

>> need to add a new protocol element for advertising a future truncation

That historic and future events have a level of uncertainty is a fact of
life :) Adding truncation on both ends of the process does make sense.
Initially as a global setting, but at some future point it would perhaps
be tidier to allow data related limits? Simply trying to avoid adding
some now which would block that later option.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 27 Aug 2014 10:03:59 -0400

Hi Lester,

> some now which would block that later option.

Based on Paul's comments it seems like the "range of validity" is a 
per-time zone value rather than something global to the entire server. Yes 
the server can itself apply truncation to limit the "range of values", but 
that is arguably a different range than the range of validity.

iCalendar itself does not have a way to express such a range in a VTIMEZONE 
object. Perhaps a better choice would be to treat that as "meta-data" and 
have it be an attribute returned in the action=list response.

-- 
Cyrus Daboo

---

From: Daniel Migault <[email-masked]>
Date: Wed, 27 Aug 2014 21:25:08 +0200

So my understanding is that the best way would be to use VTIMEZONE to
specify a range of validity. However VTIMEZONE enables such truncation in
the past but not in the future.
Can you explain why it is not feasible ? Would it be possible to extend
VTIMEZONE to enable it?

Currently, I think it would be better to have this range specification in
the data, instead of in meta-data. Any opinion on that?

BR,
Daniel

On Wed, Aug 27, 2014 at 4:03 PM, Cyrus Daboo <[email-masked]> wrote:

> iCalendar itself does not have a way to express such a range in a
> VTIMEZONE object. Perhaps a better choice would be to treat that as
> "meta-data" and have it be an attribute returned in the action=list
> response.
>
> --
> Cyrus Daboo
>
>
> _______________________________________________
> Tzdist mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist
>

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Tim Parenti <[email-masked]>
Date: Wed, 27 Aug 2014 15:37:17 -0400

I support Paul's revised text here, subject to possible further
clarification about when the year starts and ends, per
http://trac.tools.ietf.org/wg/tzdist/trac/ticket/21  I especially emphasize
my support for the changes to the second paragraph.

> "meta-data" and have it be an attribute returned in the action=list

Yes, since the "range of validity" always has some finite beginning point,
the idea of "untruncated" data doesn't really make sense, since data
covering all of time will necessarily be invalid (or be otherwise devoid of
meaning) for times in the far past and the far future.  (How far forward we
assume the rules are valid is a different matter, but for now, tz isn't
doing much past 2038.  We ought to allow for when that changes.)

I think this ties into http://trac.tools.ietf.org/wg/tzdist/trac/ticket/10
somewhat, the idea that global truncation is perhaps not really the most
reasonable concept here.

--
Tim Parenti

---

From: Paul Eggert <[email-masked]>
Date: Wed, 27 Aug 2014 13:09:13 -0700

Daniel Migault wrote:
> However VTIMEZONE enables such truncation in

Can't one use VTIMEZONE to represent truncation in the future, by 
appending a dummy tzprop component whose tzstart specifies the end 
truncation date?  For compatibility with existing applications the dummy 
tzprop could contain any TZOFFSETTO and TZNAME values it likes, since 
(if I'm understanding things correctly) these values should not be used 
by a properly-operating client.  We could suggest using the dummy 
TZOFFSETTO value of "+0000" (I wish "-0000" were not prohibited by the 
iCalendar spec...) and a dummy TZNAME of "truncated".

This raises another issue, which I hadn't thought about until just now: 
how should the protocol represent time zones where the UTC offset is 
undefined for some eras?  For example, from 1957 to 1964 
Antarctica/Davis was inhabited and so had a defined UTC offset, but it 
was then abandoned until 1969 and so its UTC offset was undefined from 
1964 until 1969.  One possibility is to use dummy tzprop entries 
containing "TZOFFSETTO:+0000" and "TZNAME:zzz" for such eras.  This 
would build on the idea of using a dummy to represent future truncation, 
and would mimic what the tz database already does in this situation.

It might be nicer to extend VTIMEZONE to represent this sort of thing 
properly, but I expect that's out of scope for tzdist.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 28 Aug 2014 07:46:30 +0200

On 8/27/14, 10:09 PM, Paul Eggert wrote:
> This raises another issue, which I hadn't thought about until just
> now: how should the protocol represent time zones where the UTC offset
> is undefined for some eras?  For example, from 1957 to 1964
> would build on the idea of using a dummy to represent future
> truncation, and would mimic what the tz database already does in this
> situation.

I'd like to restate your question:

Does the protocol need to assume continuity?  I think the answer is "no"
for the same reason that the TZ database doesn't have continuity in this
regard, which is that if nobody was living there why would anyone care
what the offset was at the time?

Eliot

---

From: Daniel Migault <[email-masked]>
Date: Sat, 30 Aug 2014 20:21:12 +0200

On Wed, Aug 27, 2014 at 10:09 PM, Paul Eggert <[email-masked]> wrote:

> tzprop could contain any TZOFFSETTO and TZNAME values it likes, since (if
> I'm understanding things correctly) these values should not be used by a
> properly-operating client.  We could suggest using the dummy TZOFFSETTO
> value of "+0000" (I wish "-0000" were not prohibited by the iCalendar
> spec...) and a dummy TZNAME of "truncated".
>
> undefined for some eras?  For example, from 1957 to 1964 Antarctica/Davis
> was inhabited and so had a defined UTC offset, but it was then abandoned
> until 1969 and so its UTC offset was undefined from 1964 until 1969.  One
> possibility is to use dummy tzprop entries containing "TZOFFSETTO:+0000"
> and "TZNAME:zzz" for such eras.  This would build on the idea of using a
> dummy to represent future truncation, and would mimic what the tz database
> already does in this situation.
>
> If we agree that the proper way to solve this issue is to extend
VTIMEZONE. Then, I believe we should mention our motivations to explain why
this should not be handled by the TZ Data distribution Service.
Specification of the VTIMEZONE extension will be defined in another
document, which is left for future work.

I guess the question is do we agree that it should be handled with a
VTIMEZONE extension and not by the time zone distribution protocol?

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Paul Eggert <[email-masked]>
Date: Sat, 30 Aug 2014 17:50:49 -0700

> VTIMEZONE extension and not by the time zone distribution protocol?

I wasn't proposing to wait until a VTIMEZONE extension could be 
standardized.  I was proposing to use unextended, ordinary VTIMEZONE. 
That is, tzdist would use ordinary VTIMEZONE format, and would specify 
the interpretation or formatting of certain information that RFC 5545 
leaves unspecified.  It could be thought of as a VTIMEZONE profile, I 
suppose.  The draft already imposes restrictions on tzdist-based 
VTIMEZONE data (e.g., in Section 3.4) and it could easily impose a few more.

If VTIMEZONE is extended in the future I suppose that would be nice too, 
but why wait?