Subject: [Tzdist] draft-ietf-tzdist-service 8.2. Equivalent Time Zone Identifier Property

From: Tobias Conradi <[email-masked]>
Date: Sun, 21 Sep 2014 05:55:02 +0200

Property Name:  EQUIVALENT-TZID

This property specifies an equivalent time zone
      identifier for a "VTIMEZONE" component when the "TZID" property of
      the time zone is an alias identifier.

-----
If it is an alias, call it alias:

TZID-ALIAS

has the benefits
- sorting next to TZID in a alphabetical listing of properties
- shorter
- does not use the word "equivalent" which has a specific meaning in English

I would contest that the each alias given in the examples is
equivalent to TZID it is listed for.

There is
TZID:US/Eastern
   EQUIVALENT-TZID:America/New_York
   EQUIVALENT-TZID:America/Montreal

http://www.travelmath.com/time-zone/America/Montreal
returns
"Comments: Eastern Time - Quebec - most locations"

Nearby time zones
...
America/New_York
...

http://www.travelmath.com/time-zone/America/New_York
Comments: Eastern Time

If zone C is nearby to zone B, then B and C are not equivalent. Then
it cannot be that both are equivalent to any zone X, including to the
specific zone A.

Use
A = US/Eastern
B = America/Montreal
C = America/New_York

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 30 Sep 2014 15:56:53 +0100

Hi Tobias,

> If it is an alias, call it alias:

I would be OK making this change and will do so if there are no objections.

-- 
Cyrus Daboo

---

From: Ken Murchison <[email-masked]>
Date: Tue, 30 Sep 2014 11:16:46 -0400

> I would be OK making this change and will do so if there are no 

EQUIVALENT-TZID was intended to be the actual tzid (e.g. 
America/New_York) that the alias TZID (e.g. US/Eastern) points to.  
Since America/New_York is the actual zone per the IANA tzdata, calling 
it an alias doesn't seem correct to me.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 30 Sep 2014 16:37:28 +0100

Hi Ken,

--On September 30, 2014 at 11:16:46 AM -0400 Ken Murchison 
<[email-masked]> wrote:

> America/New_York) that the alias TZID (e.g. US/Eastern) points to.  Since
> America/New_York is the actual zone per the IANA tzdata, calling it an
> alias doesn't seem correct to me.
>

Yes you are right. A better property name would be "TZID-ALIAS-OF". That 
keeps the TZID prefix and properly identifies what it represents.

-- 
Cyrus Daboo

---

From: Tobias Conradi <[email-masked]>
Date: Tue, 30 Sep 2014 17:39:54 +0200

On Tue, Sep 30, 2014 at 5:16 PM, Ken Murchison <[email-masked]> wrote:
> EQUIVALENT-TZID was intended to be the actual tzid (e.g. America/New_York)
> that the alias TZID (e.g. US/Eastern) points to.

Example in
https://tools.ietf.org/html/draft-ietf-tzdist-service-01#section-8.2

suggest otherwise

EQUIVALENT-TZID:US/Eastern

In case "If it is an alias" is answered with "it is not." and it is
the "actual tzid", then call it ACTUAL-TZID.

Because if equivalence works in two directions the term (EQUIVALENT)
is not describing the content (ACTUAL).

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 30 Sep 2014 16:48:01 +0100

Hi Tobias,

> EQUIVALENT-TZID:US/Eastern

Yes that is wrong and I have already fixed that in my working copy whilst 
going making the changes for this issue.

> is not describing the content (ACTUAL).

ACTUAL-TZID or TZID-ALIAS-OF?

I think I prefer keeping the term "alias" in there somewhere because that 
makes it easier to relate to the existing discussion of aliases in the 
spec. But the important thing is the definition of the properly needs to be 
absolutely clear about what it describes and I will work on some 
clarifications there.

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Tue, 30 Sep 2014 16:57:18 +0100

> keeps the TZID prefix and properly identifies what it represents.

That we are using an alternate set of data rather than a unique set for
that 'reference' is perhaps not relevant? Especially since that data may
already be a composite of other data. The only time that -OF becomes
relevant is perhaps if we had a unique set of data originally but has
now been changed to an alias? It's the conflict between identifying a
data set and how that is associated with a location that is part of the
problem here.

-- 
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: Tobias Conradi <[email-masked]>
Date: Tue, 30 Sep 2014 18:25:41 +0200

On Tue, Sep 30, 2014 at 5:48 PM, Cyrus Daboo <[email-masked]> wrote:

> makes it easier to relate to the existing discussion of aliases in the spec.

And it is probably a better description of what it is.

If data for a TZ has an ID and aliases, then probably there is still a
need for TZID-ALIAS?

Then the data set for TZID=<string 1> can list all the TZID aliases as

TZID-ALIAS=<string 2>
TZID-ALIAS=<string 3>

I now re-read more of the doc, and another point suggest
EQUIVALENT-TZID meant alias

   Conformance:  This property can be specified zero or more times
      within "VTIMEZONE" calendar components.

_if_ there is one TZID per TZ and zero or more aliases.

"zero or more" could not refer to the TZID of a zone, could it?

On the other hand, in
https://tools.ietf.org/html/draft-ietf-tzdist-service-01#section-3.2
one alias links to two IDs it seems to be meant as an alias for:
-----------------
 When
   returning time zone data to a client, the server returns the data
   with an identifier matching the query, but it can include one or more
   equivalent identifiers in the data to provide a hint to the client
   that alternative identifiers are available.  For example, a query for
   "US/Eastern" could include equivalent identifiers for "America/
   New_York" or "America/Montreal".
------------------

Other terms that could be used

TZID-PRIMARY
TZID-SECONDARY

But before choosing a term, it would be good to know what the
properties shall contain.

It seems as if this is only designed because in the IANA TZDB exists a
mechanism of TZID mapping?

Or does such a mechanism also exist in the IATA TZDB or the Microsoft TZDB?

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com