John Stracke wrote:
>
> Doug Royer wrote:
>
> > I think that only one should be the IANA registered name.
> > The other(s) some kind of alias.
>
> I think I need to disagree here--almost. My thoughts:
>
> First: we need to permit all the names, because people are using them (or,
> at least, we can't be sure that people aren't using them, which is just as
> bad).
I think we MUST be able to find a VTIMEZONE given common names.
(1) However are you saying that ALL must be the 'standard' IANA
registered name?
(2) Or are you saying that only ONE (the Olson name)
is the IANA name, and the others are just in there somewhere?
I think I was saying - (2).
> For example, Unix boxen generally have the Olsen database installed
> (on my RedHat6.2 box it's under /usr/share/zoneinfo); a program running on
> a Unix box ought to be able to look at the system's timezone and use that
> as its default. Since the database is installed with all the names, the
> program needs to be able to use any of them.
Use all? - Yes.
All names a standard name? - I think - no.
I may have asked badly. I meant to ask, how do we specify
the non-standard names so they are fetchable? -OR- do we
specify all as standard?
> Next: clearly, all the names need to be standardized; otherwise, it won't
> be safe to use the ones that aren't. So all the names need to
> be IANA registered.
Or do we register that FOO is the standard name, and that FOO-OLD
is another name that can be used to find the FOO VTIMEZONE data as
part of the FOO registration?
If a timezone server were setup. Could (should?) we:
client: Ask server for FOO-OLD time zone.
server: I know what FOO-OLD is. However it's not the
official name, so I'll return:
success - code followed by:
BEGIN:VTIMEZONE
TZID:FOO
...
<unspecified-at-this-time>:FOO-OLD
...
END:VTIMEZONE.
So that you can get what you need, but are also informed of what
you should ask for in the future (ask for FOO).
> Next: I agree that it would be best to register each set of data just
> once (hence the "almost disagree"). So either we register some names with
> data, and some with pointers; or we register data with multiple names. (I
> don't have strong feelings either way here.) Either way, some of the names
> are aliases.
(1) We currently do not have any way to do a 'pointer' inside
if VTIMEZONE data.
(2) I think you are asking the same question as me.
> Finally: I do not think that we should distinguish syntactically between
> canonical names and alias names (in your examples, by putting a slash in
> front of some but not others).
This is already part of RFC2445, search for the string 'tzidprefix'.
It is how the WG already decided to identify IANA registered TZIDs.
My question is do we register all (The Olson alias people seem so far
to be saying - no - they exist for historical use), or just the
current names.
> This is, admittedly, partly just technical
> aesthetics, but there is also a practical reason: one nice use of the alias
> names is to permit future transitions. Suppose we know that Pennsylvania
> is planning to change its DST rules in a year or so, but the details aren't
> nailed down yet. We define an "America/Pennsylvania" alias, which points
> to EST5EDT, and start using it in iCalendars for events in Pennsylvania.
> When the DST rules are finalized, we change the alias to be a canonical
> name for the new data; suddenly, all the existing iCalendars for
> Pennsylvania events refer to the changed data. (This assumes that the
> legislature isn't dumb enough to change DST retroactively, so it's valid to
> change the data that the iCalendar refers to, since it's in the future.
> :-) If we had to distinguish between "America/Pennsylvania" and
> "/America/Pennsylvania", this wouldn't work; we'd have to go through all
> the existing iCalendars and change the TZIDs.
That's not exactly the way it works.
Using your example, If 'America/Pennsylvania' already existed and
was registered by IANA, then its IANA registered name (It's IANA TZID) is
going to be '/America/Pennsylvania' (leading slash - per RFC2445).
So if it were to be updated, the TZID could be the same. However
the data inside would be updated. And the old value would have
at least a new UNTIL to it's RRULE. And the DTSTAMP would be updated.
(I think we need to make DTSTAMP a MUST for registration).
If the name 'America/Pennsylvania' were not already registered.
Then there is no conflict. Once it were to be registered, then
'that' new data 'is' the data and the TZID would be
'/America/Pennsylvania'. So there would be no issue.
It would NOT be possible to have 'America/Pennsylvania' and
'/America/Pennsylvania' BOTH registered as the leading slash
means it is registered.
Asking for 'America/Pennsylvania' would be asking for
any VTIMEZONE that had this name. being returned the
same name with the 'tzidprefix' simply tells you it is a
registered name.
Or did I miss your point ;-)
-DougAttachment:
smime.p7s
Description: S/MIME Cryptographic Signature