Subject: [calsify] JSCalendar timezones

From: Robert Stepanek <[email-masked]>
Date: Thu, 14 Feb 2019 17:01:51 +0100

At CalConnect XLIV last week, the need for a non-IANA time zone
identifiers and custom time zone definitions was raised. We'd like to
discuss options how to support them in JSCalendar.
Currently, an event's timezone in JSCalendar is defined in the
timeZone property, which is of string type.  Its value must be a name
in the IANA time zone database, or null for floating time (see the
latest spec here[1]).
We discussed, if to replace the string value with a URI. That way we
could either use a IANA time zone database name in a to be defined URI
scheme, or e.g. could embed custom VTIMEZONEs in a data URI.However, on second thought we'd rather prefer a different solution,
because URIs in iCalendar parameters could cause breakage on ill-
behaving clients. There also wouldn't be an obvious urn namespace or URI
scheme to use for IANA names, AFAIK.
Alternatively, we could keep the time zone identifier as string value,
and use the same escape mechanism with a SOLIDUS character as specified
in RFC 5545  (see section 3.8.3.1[2]). All time zone identifiers that do
not start with SOLIDUS must be an IANA time zone. For custom timezones,
we might want to consider defining a JSON representation of time zones,
which could be defined in a timeZones property on the JSCalendar object,
keyed by their time zone identifier.
Do you have other suggestions on how to handle non-IANA timezones in
JSCalendar?
Cheers,
Robert

Links:

  1. https://tools.ietf.org/html/draft-ietf-calext-jscalendar-11
  2. https://tools.ietf.org/html/rfc5545#section-3.8.3.1

---

From: Daniel Migault <[email-masked]>
Date: Thu, 14 Feb 2019 12:17:53 -0500

Hi Robert,

I am adding tzdist-bis in the discussion.

Not being URN expert, I have the feeling that using a SOLIDUS would be used
to define global identifiers versus non global and that URI might be more
appropriated. I would as much as possible prevent global identifiers scheme
be impacted by ill-clients.

I believe inputs from people that have more expertise on urn would be
welcome.

Yours,
Daniel

On Thu, Feb 14, 2019 at 11:03 AM Robert Stepanek <[email-masked]>
wrote:

> Currently, an event's timezone in JSCalendar is defined in the timeZone
> property, which is of string type.  Its value must be a name in the IANA
> time zone database, or null for floating time (see the latest spec here
> <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-11>).
>
> We discussed, if to replace the string value with a URI. That way we could
> either use a IANA time zone database name in a to be defined URI scheme, or
> e.g. could embed custom VTIMEZONEs in a data URI.
> However, on second thought we'd rather prefer a different solution,
> because URIs in iCalendar parameters could cause breakage on ill-behaving
> clients. There also wouldn't be an obvious urn namespace or URI scheme to
> use for IANA names, AFAIK.
>
> Alternatively, we could keep the time zone identifier as string value, and
> use the same escape mechanism with a SOLIDUS character as specified in RFC
> 5545  (see section 3.8.3.1
> <https://tools.ietf.org/html/rfc5545#section-3.8.3.1>). All time zone
> identifiers that do not start with SOLIDUS must be an IANA time zone. For
> custom timezones, we might want to consider defining a JSON representation
> of time zones, which could be defined in a timeZones property on the
> JSCalendar object, keyed by their time zone identifier.
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify
>