Subject: [Tzdist] Ticket #21 - proposed changes

From: Cyrus Daboo <[email-masked]>
Date: Wed, 03 Sep 2014 10:13:09 -0400

Hi,
Starting a new thread on this since I think we have converged on what needs 
to be done and we can now focus on the specific changes to the draft.

Here is what I think needs to be changed:

1) Truncation precision: we will require that truncation use the full 
precision of RFC3339 date-time values (down to seconds).

2) Servers can advertise fixed truncation ranges using [start,end) 
nomenclature and those can be retrieved by the client.

3) Servers MAY support client-specified arbitrary truncation (as is 
currently specified in the draft) and will need to do so at full RFC3339 
precision.

4) Do we want to continue the concept of "untruncated" data as supported by 
the current draft? That might be needed by secondary servers to sync the 
data over the largest range supported by the primary.

5) We will define two new properties for VTIMEZONE components: TZSTART, 
TZEND that define the overall range of validity for the time zone data 
described by the VTIMEZONE object. Servers will be required to include 
those in any truncated data they return.

6) Expand precision: the start/end query parameters for action=expand will 
use full RFC3339 precision.

7) Observances in UTC: the "onset" member in the "observance" object in the 
action=expand JSON response will be a UTC value.

-- 
Cyrus Daboo

---

From: Ken Murchison <[email-masked]>
Date: Wed, 03 Sep 2014 10:28:20 -0400

Hi Cyrus,

I agree on all points, including "yes" to #4.

Question on #5.  If the last zone rule is non-terminating (e.g. 
America/New_York), should TZEND be omitted or include a some value 
anyways, such as the 32-bit signed limit or something like 
9999-12-31T23:59:59 Z?

On 09/03/2014 10:13 AM, Cyrus Daboo wrote:
> Hi,
> Starting a new thread on this since I think we have converged on what 
> needs to be done and we can now focus on the specific changes to the 
> draft.
>
> currently specified in the draft) and will need to do so at full 
> RFC3339 precision.
>
> 4) Do we want to continue the concept of "untruncated" data as 
> supported by the current draft? That might be needed by secondary 
> servers to sync the data over the largest range supported by the primary.
>
> 5) We will define two new properties for VTIMEZONE components: 
> TZSTART, TZEND that define the overall range of validity for the time 
> zone data described by the VTIMEZONE object. Servers will be required 
> to include those in any truncated data they return.
>
> 6) Expand precision: the start/end query parameters for action=expand 
> will use full RFC3339 precision.
>
> 7) Observances in UTC: the "onset" member in the "observance" object 
> in the action=expand JSON response will be a UTC value.
>

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Lester Caine <[email-masked]>
Date: Wed, 03 Sep 2014 16:14:08 +0100

On 03/09/14 15:13, Cyrus Daboo wrote:
> 4) Do we want to continue the concept of "untruncated" data as supported
> by the current draft? That might be needed by secondary servers to sync
> the data over the largest range supported by the primary.

The concept is still correct as long a suitable source is available. My
real objection at the moment is that the current tz default data IS
truncated since know good material is omitted. Serving that against a
'fuller' dataset means that 'untruncated' is variable, The real problem
requires a better handling of describing how a dataset is truncated, and
I think '5' at least covers part of the problem!

tz currently serves up the wrong data for some tzid's which are aliased
to a tzid which matches at some later point in time. The 1970 limit is
quoted as the rule for this merge but in reality it is an earlier point
that the times diverge, but just how we correct this problem is not so
obvious?

My suggestion as a way forward of of simply ignoring anything prior to
1970 just to get moving stops publishing know incorrect data, but also
prevents valid historic data. I know we are not talking about a lot of
tzid's but if I start serving them with the correct data and other
servers are using the truncated set without some indication to that fact?

-- 
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: Lester Caine <[email-masked]>
Date: Wed, 03 Sep 2014 16:28:18 +0100

On 03/09/14 15:28, Ken Murchison wrote:

>> TZSTART, TZEND that define the overall range of validity for the
>> time zone data described by the VTIMEZONE object. Servers will be
>> required to include those in any truncated data they return.

> anyways, such as the 32-bit signed limit or something like

The end point is more technology limited than unlimited, so unless there
is a rule based reason for an end point, some other factor comes in, and
while 9999 may be achievable, a more practical limit may be better in
the short term. You do not want to 'expand' 10000 years, more likely 10
or 20 years, so 2038 may be better as a start for then next few years?

Do we actually need the TZEND, only if it is a rule based limit?

---

From: Tim Parenti <[email-masked]>
Date: Wed, 3 Sep 2014 12:23:38 -0400

On 3 September 2014 10:13, Cyrus Daboo <[email-masked]> wrote:

> needs to be done and we can now focus on the specific changes to the draft.
>

Thanks, Cyrus.  I'll tie these back into the numbered questions I posed at
http://www.ietf.org/mail-archive/web/tzdist/current/msg00363.html to
convince myself we've covered everything there, and will add further

> precision of RFC3339 date-time values (down to seconds).

I believe this addresses the server-side of (21b).  We should do this in
universal time to cover (21a) as well.

> nomenclature and those can be retrieved by the client.

This sounds good.

> currently specified in the draft) and will need to do so at full RFC3339

This addresses the client-side of (21b).

> by the current draft? That might be needed by secondary servers to sync the

I think we need to clarify just what exactly is meant by the various forms
of truncation: server-specified and client-specified.

Server-specified truncation will be advertised by (1) and (2) here, and
this should be a single range over which the server expects to be able to
handle requests.  Client-specified truncation will be addressed by (3)
here, when supported by a server.

I think, from a performance perspective, there would be room for a middle
layer, where the server advertises precomputed subsets of its data that it
has cached; such as a 64-bit server caching a 32-bit subset for the
convenience of 32-bit clients.  This could be any number of ranges which
are subsets of the server range.  Perhaps this is what (2) is getting at,
in which case I think the full range available should additionally be
specified, separate from any precomputed subsets.

I believe, if we are in agreement on something resembling the above
definitions, this may also address ticket 10.
http://trac.tools.ietf.org/wg/tzdist/trac/ticket/10

> those in any truncated data they return.

For many zones their rules are theoretically extendable into ±infinity.  In
the most trivial cases, this involves extending an LMT value backwards and
a single constant offset forwards.  In the next simplest cases, this
involves extending a recurring ruleset forwards instead.  There are several
zones with rules based in non-Gregorian calendars for which extension
toward +infinity is not currently feasible given the structure of the
underlying data.

As a practical measure, then, at least the last group will necessarily have
to be truncated on one end.  But for theoretically infinite ranges, it may
be wise to allow for TZSTART and TZEND to contain some non-RFC3339 sentinel
value such as -INF or +INF to indicate this property if a server desires to
treat such a zone in that way.

This covers (21c) in part, but we will need to do something similar for the
action=expand JSON responses, too.  Perhaps we should bring the rest of
ticket 15 into this?
http://trac.tools.ietf.org/wg/tzdist/trac/ticket/15

I think it is good that this defines the range of validity on a
per-response, per-timezone basis.  Just because my request for [2000,2100)
in America/New_York may return useful data, it doesn't mean my request for
[2000,2100) in Africa/Cairo will return anything of use past 2038-01-19.

> use full RFC3339 precision.

Servers should be prepared for valid non-universal time RFC3339 dates such
as "2014-09-03T12:00:00-04:00" and interpret them accordingly.  They should
return, e.g., "2014-09-03T16:00:00Z" as the corresponding bound in their
response, however, to address (21d).

Are we in favor of allowing clients to request something like [1990,2010)
and having the server expand this to full-precision RFC3339?  If so, we
should specify this mechanism (e.g., "month and date are assumed 01; hour,
minute, second are assumed 00; unless otherwise specified").

This may not be necessary, but would be backwards-compatible with the
year-based system in the earlier draft.

> 7) Observances in UTC: the "onset" member in the "observance" object in
> the action=expand JSON response will be a UTC value.
>

This addresses (21e).

--
Tim Parenti

---

From: Paul Eggert <[email-masked]>
Date: Wed, 03 Sep 2014 11:28:05 -0700

> Here is what I think needs to be changed:

Thanks, that all looks good.  I have the following comments on this 

> the data over the largest range supported by the primary.

Don't servers tell clients the ranges they support?  If so, the 
"untruncated" data will be a largest supported range, and there's no 
need for a special case for "untruncated".

Or perhaps you're thinking about the problem of servers or clients that 
support time stamps outside the ISO 8601 / RFC 3339 range?  Assuming we 
don't extend RFC 3339 to allow arbitrary integer year numbers, we'll 
need some other way to allude to ranges that go past the RFC 3339 
limits, e.g., the -INF and +INF values that Tim Parenti mentioned.  Or 
perhaps we could simply omit TZSTART, TZEND, or DTSTART components that 
fall outside the RFC 3339 range, i.e., omitted values would default to 
negative or positive infinity as appropriate.  (At some point the time 
nerds may well extend RFC 3339 to cover wider date ranges, but if and 
when that happens we can come up with tzdist version 2....)

This business about outlandishly large dates is not entirely academic. 
The standard tzcode distribution formerly generated a transition at the 
POSIX time equal to -2**63 seconds before 1970 (roughly 292 billion 
years ago) in order to mark the start of the first region it supported. 
  This broke some client software that foolishly tried to subtract 1 
from -2**63, so in release 2014d we changed tzcode so that the generated 
transition is now at the POSIX time -2**59 (roughly 18 billion years 
ago).  The ISO 8601 / RFC 3339 limitations on years means that the 
tzdist protocol cannot represent this -2**59 transition, and presumably 
when these time zone data files are converted to VTIMEZONE the -2**59 
placeholders should be omitted, or turned into -INF, or turned into 
year-0 placeholders, depending on how we decide to address 
out-of-ISO-8601-range time stamps.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 03 Sep 2014 14:31:18 -0400

> to include those in any truncated data they return.

UTC or local time (like DTSTART for all VTIMEZONE components)?

---

From: Tim Parenti <[email-masked]>
Date: Wed, 3 Sep 2014 14:33:12 -0400

> UTC or local time (like DTSTART for all VTIMEZONE components)?

I think we're pretty much settled on using universal time in all places,
unless there are any major objections outstanding.

--
Tim Parenti

---

From: Paul Eggert <[email-masked]>
Date: Wed, 03 Sep 2014 11:43:11 -0700

> UTC or local time (like DTSTART for all VTIMEZONE components)?

TZSTART and TZEND should definitely be UTC.  Even DTSTART should be UTC. 
  Allowing local times as part of the specification for Local Time is a 
recipe for trouble.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 03 Sep 2014 14:47:03 -0400

On 09/03/2014 02:43 PM, Paul Eggert wrote:
> TZSTART and TZEND should definitely be UTC.  Even DTSTART should be 
> UTC.  Allowing local times as part of the specification for Local Time 
> is a recipe for trouble.

DTSTART is already mandated to be local time in VTIMEZONE sub-components 
by RFC 5545.  I don't think we want to change that here since it will 
probably break a lot of existing code.

TZSTART/TZEND are new we can certainly enforce UTC if desired.

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 03 Sep 2014 14:48:08 -0400

Hi Ken,

> UTC or local time (like DTSTART for all VTIMEZONE components)?

In this case a local time does not make much sense since it would be 
relative to the time zone the limits are themselves trying to set a bound 
for. So TZSTART/TZEND would be required to be UTC values.

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Wed, 03 Sep 2014 19:50:06 +0100

On 03/09/14 17:23, Tim Parenti wrote:
> As a practical measure, then, at least the last group will necessarily
> have to be truncated on one end.  But for theoretically infinite ranges,
> it may be wise to allow for TZSTART and TZEND to contain some
> non-RFC3339 sentinel value such as -INF or +INF to indicate this
> property if a server desires to treat such a zone in that way.

My own view of 'timezone' is that they did not start until a number of
diverse locations agreed on a standard time, so only within the last few
hundred years. Prior to that start date, every location simply used it's
own LMT and so a tzid is simply not relevant. It is inappropriate to be
flagging a tzid prior to the start date, and this is one area that
backzone contains different dates to the default distribution, and it is
that transition I need to be correct.

That is unless someone comes up with evidence of synchronised sundials
in BC dates :)

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 03 Sep 2014 14:55:21 -0400

Hi Paul,

> Allowing local times as part of the specification for Local Time is a

But that is exactly what the tzdb data itself does:

Rule	US	2007	max	-	Nov	Sun>=1	2:00	0	S

translates to iCalendar as:

DTSTART:20071104T020000

i.e., the local time relative to the prior observance is used. Since the 
iCalendar data also has:

TZOFFSETFROM:-14400

getting the UTC value is trivial. The point here is that a local time is 
being used to "pin" the transition time from one offset to the other 
relative to the original local time.

In any case, we can't change the existing iCalendar behavior without 
breaking every client in existence so we only need to worry about the new 
properties we are adding.

-- 
Cyrus Daboo

---

From: Tim Parenti <[email-masked]>
Date: Wed, 3 Sep 2014 14:55:39 -0400

> That is unless someone comes up with evidence of synchronised sundials

Yes, a reasonable alternative to extending zones backwards to -INF would be
that zones are considered to "start" with the first transition away from
LMT to anything more coordinated (which, in a few cases like
Asia/Yekaterinburg in 2014g, is indeed an LMT value for some other nearby
location).  If people need an offset from before then, they would have to
resort to using geographical coordinates.

I could see either approach being valid, but it seems we should pick one.
I think I know your choice, Lester.  ;)

--
Tim Parenti

---

From: Lester Caine <[email-masked]>
Date: Wed, 03 Sep 2014 19:56:48 +0100

On 03/09/14 19:47, Ken Murchison wrote:
> by RFC 5545.

I was looking at that while I was playing with the version control stuff
and came to the conclusion that the 'local time' was that of the
'server' which would be UTC rather than some random offset. It's use of
'local time' on a server that causes most of the agro, but as soon as
all servers are running UTC it all becomes easy.

---

From: Tim Parenti <[email-masked]>
Date: Wed, 3 Sep 2014 14:57:59 -0400

So correct me if I'm wrong, but we're saying...

In iCalendar responses:
Local for DTSTART rules for compatibility with previous specs.
Universal for our new TZSTART and TZEND.

In JSON responses:
Universal for everything?

--
Tim Parenti

On 3 September 2014 14:55, Cyrus Daboo <[email-masked]> wrote:

> Hi Paul,
>
>
> --On September 3, 2014 at 11:43:11 AM -0700 Paul Eggert <
> [email-masked]> wrote:
>
> _______________________________________________
> Tzdist mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist
>

---

From: Tim Parenti <[email-masked]>
Date: Wed, 3 Sep 2014 15:01:00 -0400

On 3 September 2014 14:56, Lester Caine <[email-masked]> wrote:

> [I] came to the conclusion that the 'local time' was that of the
> 'server'
>

I don't think anyone ever suggested that.  The discussion has been between
(a) universal time and (b) the local time corresponding to the zone in
question.

I agree it would be a bit ridiculous for a server located in Sydney to say
that New York falls back at 2014-11-02T17:00+11:00, but this was never
suggested here.

--
Tim Parenti

---

From: Paul Eggert <[email-masked]>
Date: Wed, 03 Sep 2014 12:01:30 -0700

> DTSTART is already mandated to be local time in VTIMEZONE sub-components

Ouch.  I didn't know that, sorry.  I guess we're stuck with it then.

I expect this means VTIMEZONE can't represent the time zone rules in 
western Greenland (which are based on UTC and cannot be rejiggered to 
local time).  Maybe at some point VTIMEZONE should get fixed, but that'd 
be an issue for later.

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 03 Sep 2014 15:03:35 -0400

Hi Tim,

> Universal for everything?

Yes.

-- 
Cyrus Daboo

---

From: Tim Parenti <[email-masked]>
Date: Wed, 3 Sep 2014 15:17:08 -0400

>> Universal for everything?

Alright, then I support this.

On 3 September 2014 15:01, Paul Eggert <[email-masked]> wrote:

> western Greenland (which are based on UTC and cannot be rejiggered to local
> time).  Maybe at some point VTIMEZONE should get fixed, but that'd be an
> issue for later.

Agreed.

--
Tim Parenti

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 03 Sep 2014 15:17:28 -0400

Hi Paul,

> local time).  Maybe at some point VTIMEZONE should get fixed, but that'd

I think I have been able to accurately convert tzdb into iCalendar - 
including those UTC and standard time based transitions. Can you point to 
the specific tzdb Rule you are referring to?

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Wed, 03 Sep 2014 20:20:40 +0100

On 03/09/14 19:55, Tim Parenti wrote:
> 
> On 3 September 2014 14:50, Lester Caine <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> Yes, a reasonable alternative to extending zones backwards to -INF would
> be that zones are considered to "start" with the first transition away
> from LMT to anything more coordinated (which, in a few cases like
> Asia/Yekaterinburg in 2014g, is indeed an LMT value for some other
> nearby location).  If people need an offset from before then, they would
> have to resort to using geographical coordinates.
> 
> I could see either approach being valid, but it seems we should pick
> one.  I think I know your choice, Lester.  ;)

As I've already said, you need that transition, and you need to flag
that PRIOR to that transition the tzoffset does not apply, so why not
just make that the initial truncation? Fixes all the problems?

---

From: Ken Murchison <[email-masked]>
Date: Wed, 03 Sep 2014 15:23:44 -0400

On 09/03/2014 03:17 PM, Cyrus Daboo wrote:
> including those UTC and standard time based transitions. Can you point 
> to the specific tzdb Rule you are referring to?
>

I too am curious which Zones/Rules may be problematic since I can now 
"expand" all of my VTIMEZONEs into zdump-formatted output which exactly 
matches that of zdump (2014g).

---

From: Lester Caine <[email-masked]>
Date: Wed, 03 Sep 2014 20:24:55 +0100

On 03/09/14 20:01, Tim Parenti wrote:
> On 3 September 2014 14:56, Lester Caine <[email-masked]
> I don't think anyone ever suggested that.  The discussion has been
> between (a) universal time and (b) the local time corresponding to the
> zone in question.
> 
> I agree it would be a bit ridiculous for a server located in Sydney to
> say that New York falls back at 2014-11-02T17:00+11:00, but this was
> never suggested here.

But dtstart base is the one used by the list function, and I'm still
looking at the same value matching all the expand packets served from
that list. changedsince should work with a single value, not a whole
range, and the ZTIMEZONE has to be in sync with that.

---

From: Tim Parenti <[email-masked]>
Date: Wed, 3 Sep 2014 15:26:09 -0400

> the specific tzdb Rule you are referring to?

I believe he's referring to America/Godthab, which reads:
Zone America/Godthab    -3:26:56 -  LMT 1916 Jul 28 # Nuuk
            -3:00   -   WGT 1980 Apr  6  2:00
            -3:00   EU  WG%sT

Since the EU rules take effect at 01:00 UTC on the last Sunday of a month,
this is 22:00 local standard time on the previous Saturday, which isn't as
easily expressible as a tz Rule.  Not sure about iCalendar.

--
Tim Parenti

---

From: Ken Murchison <[email-masked]>
Date: Wed, 03 Sep 2014 15:26:12 -0400

> range, and the ZTIMEZONE has to be in sync with that.

Lester,

I think you are confusing dtstamp in the list output and DTSTART in the 
VTIMEZONE components.

---

From: Paul Eggert <[email-masked]>
Date: Wed, 03 Sep 2014 12:30:30 -0700

Cyrus Daboo wrote:
> Can you point to the specific tzdb Rule you are referring to?

America/Godthab, for example, springs forward the last Sunday in March 
at 01:00 UTC.  If I understand things correctly VTIMEZONE does not allow 
the transition time to be specified in UTC, and therefore can't express 
this as a single rule that applies into the indefinite future.

(Perhaps you're expanding things, so that each year is represented 
separately?  But that would be *cheating*.  :-)

---

From: Ken Murchison <[email-masked]>
Date: Wed, 03 Sep 2014 15:30:59 -0400

On 09/03/2014 03:26 PM, Tim Parenti wrote:
>
> On 3 September 2014 15:17, Cyrus Daboo <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I think I have been able to accurately convert tzdb into iCalendar
>     - including those UTC and standard time based transitions. Can you
>     point to the specific tzdb Rule you are referring to?
>
>
> Since the EU rules take effect at 01:00 UTC on the last Sunday of a 
> month, this is 22:00 local standard time on the previous Saturday, 
> which isn't as easily expressible as a tz Rule.  Not sure about iCalendar.
>
> --
> Tim Parenti

BEGIN:VCALENDAR
PRODID:-//CyrusIMAP.org//Cyrus git2.4.17-caldav-beta10+17//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:America/Godthab
LAST-MODIFIED:20140903T192506Z
X-LIC-LOCATION:America/Godthab
BEGIN:STANDARD
TZOFFSETFROM:-032656
TZOFFSETTO:-0300
TZNAME:WGT
DTSTART:19160728T000000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:-0300
TZOFFSETTO:-0200
TZNAME:WGST
DTSTART:19800406T020000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0200
TZOFFSETTO:-0300
TZNAME:WGT
DTSTART:19800927T230000
RRULE:FREQ=YEARLY;BYMONTH=9;BYMONTHDAY=23,24,25,26,27,28,29;BYDAY=SA;UNTIL=19950924T010000Z
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:-0300
TZOFFSETTO:-0200
TZNAME:WGST
DTSTART:19810328T220000
RRULE:FREQ=YEARLY;BYMONTH=3;BYMONTHDAY=24,25,26,27,28,29,30;BYDAY=SA
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0200
TZOFFSETTO:-0300
TZNAME:WGT
DTSTART:19961026T230000
RRULE:FREQ=YEARLY;BYMONTH=10;BYMONTHDAY=24,25,26,27,28,29,30;BYDAY=SA
END:STANDARD
END:VTIMEZONE
END:VCALENDAR

---

From: Arthur David Olson <[email-masked]>
Date: Wed, 3 Sep 2014 15:31:09 -0400

The trouble is that European Union rules...
    Rule    EU    1981    max    -    Mar    lastSun     1:00u    1:00    S
    Rule    EU    1996    max    -    Oct    lastSun     1:00u    0    -
...are now followed near Godthab. Changes occur when it is the last Sunday
in Europe (between the 25th and 31st);
at those instants it's still the 24th through the 30th near Godthab, and
the 24th is not the last Saturday.

    @dashdashado

On Wed, Sep 3, 2014 at 3:17 PM, Cyrus Daboo <[email-masked]> wrote:

> Hi Paul,
>
>
> --On September 3, 2014 at 12:01:30 PM -0700 Paul Eggert <

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 03 Sep 2014 15:33:37 -0400

Hi Tim,

> easily expressible as a tz Rule.  Not sure about iCalendar.

For that one, this is what I have:

BEGIN:STANDARD
DTSTART:19800927T230000
RRULE:FREQ=YEARLY;UNTIL=19950924T010000Z;BYDAY=SA;BYMONTHDAY=23,24,25,26,2
 7,28,29;BYMONTH=9
TZNAME:WGT
TZOFFSETFROM:-0200
TZOFFSETTO:-0300
END:STANDARD

So the DTSTART is 23:00 on the day before (Saturday), and the RRULE uses 
set of seven possible dates in the BYMONTHDAY and the BYDAY=SA item to 
effectively match the right Saturday. i.e., the above matches the Saturday 
before the last Sunday of the month.

-- 
Cyrus Daboo

---

From: Paul Eggert <[email-masked]>
Date: Wed, 03 Sep 2014 12:37:48 -0700

> RRULE:FREQ=YEARLY;BYMONTH=3;BYMONTHDAY=24,25,26,27,28,29,30;BYDAY=SA

Ah, very cool, I didn't know VTIMEZONE could do that.  I stand 
corrected; VTIMEZONE doesn't need transition times to be UTC to handle 
the current tz data.

---

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

> corrected; VTIMEZONE doesn't need transition times to be UTC to handle 

The iCalendar recurrence rules can do a lot of things that make my head 
hurt!  ;)   And it gets more fun when you add in the RSCALE extension 
for non-Gregorian calendar support.

---

From: Lester Caine <[email-masked]>
Date: Wed, 03 Sep 2014 20:44:42 +0100

> I think you are confusing dtstamp in the list output and DTSTART in the

YEP ... just got there ... sorry about that ... similarity of names can
get confusing.

I do need to digest ZTIMEZONE a bit more, but I have already decided
that for my own purposes until there is an alternative, it will get
translated back closer to the tz base. That is why the fact that some
elements do NOT reverse is a problem. I may well simply go with my own
json layer for this since I'm probably going to have to be my own
publisher anyway.

---

From: Tim Parenti <[email-masked]>
Date: Wed, 3 Sep 2014 15:46:39 -0400

On 3 September 2014 15:37, Paul Eggert <[email-masked]> wrote:

> Ah, very cool, I didn't know VTIMEZONE could do that.  I stand corrected;
> VTIMEZONE doesn't need transition times to be UTC to handle the current tz
> data.

Well, in theory at least, it might still be an issue.  If we had a similar
case in reverse; i.e., a rule takes effect at 23:00 UTC on the last
Saturday of March, and is to be applied to a zone in UTC+3, can it
represent the rule taking effect at 02:00 local on the Sunday between 26
March and 1 April, inclusive?

I don't know of an actual case of this in the tz data currently, so
certainly seeing that VTIMEZONE is extended is a much lower priority.

--
Tim Parenti

---

From: Tim Parenti <[email-masked]>
Date: Wed, 3 Sep 2014 15:50:39 -0400

> certainly seeing that VTIMEZONE is extended is a much lower priority.

Actually, I just realized if we combine this with the fact that it can't
use 24:00, that causes issues with Africa/Cairo:

Rule    Egypt   2014    max -   Sep lastThu 24:00   0   -

...which Cyrus mentioned a few days ago:
http://www.ietf.org/mail-archive/web/tzdist/current/msg00284.html

--
Tim Parenti

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 03 Sep 2014 15:51:28 -0400

Hi Tim,

--On September 3, 2014 at 3:46:39 PM -0400 Tim Parenti 
<[email-masked]> wrote:

>> VTIMEZONE doesn't need transition times to be UTC to handle the current
>> tz data.
>
>

A shift into the following month can be handled using a BYYEARDAY item in 
the RRULE instead of BYMONTHDAY. That is needed for:

Which is actually 00:00 of the Friday after the last Thursday in September. 
i.e., could match 1st October.

-- 
Cyrus Daboo

---

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

On 09/03/2014 03:50 PM, Tim Parenti wrote:
>
> On 3 September 2014 15:46, Tim Parenti <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Well, in theory at least, it might still be an issue.  If we had a
>     similar case in reverse; i.e., a rule takes effect at 23:00 UTC on
>     the last Saturday of March, and is to be applied to a zone in
>     UTC+3, can it represent the rule taking effect at 02:00 local on
>     the Sunday between 26 March and 1 April, inclusive?
>
>     I don't know of an actual case of this in the tz data currently,
>     so certainly seeing that VTIMEZONE is extended is a much lower
>     priority.
>
>
> Actually, I just realized if we combine this with the fact that it 
> can't use 24:00, that causes issues with Africa/Cairo:
>

That issue isn't with iCalendar or VTIMEZONE, its with a particular 
implementation (libical) which couldn't handle a particular RRULE 
combination.  I have recently fixed that and submitted it back to that 
project.  As Cyrus stated, it can be represented just fine:

BEGIN:STANDARD
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
TZNAME:EET
DTSTART:20140926T000000
RRULE:FREQ=YEARLY;BYYEARDAY=-92,-93,-94,-95,-96,-97,-98;BYDAY=FR
END:STANDARD

---

From: Tim Parenti <[email-masked]>
Date: Wed, 3 Sep 2014 16:02:15 -0400

This still leaves me with a bad taste.  One could count BYYEARDAY forward
for dates through 28 February, or backward for dates 1 March or later, but
what happens when a transition is near New Year's Day or Leap Year Day?

In any case, it's now clear that this sits well outside our current scope,
but we should nonetheless keep a list of things to suggest as improvements
to iCalendar as things move forward:

   - Allowing use of 24:00
   - Allowing use of UTC in DTSTART for VTIMEZONE

--
Tim Parenti

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

>> similar case in reverse; i.e., a rule takes effect at 23:00 UTC on the last

---

From: Ken Murchison <[email-masked]>
Date: Wed, 03 Sep 2014 16:04:41 -0400

On 09/03/2014 03:46 PM, Tim Parenti wrote:
>
> On 3 September 2014 15:37, Paul Eggert <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     corrected; VTIMEZONE doesn't need transition times to be UTC to
>     handle the current tz data.
>
>
> similar case in reverse; i.e., a rule takes effect at 23:00 UTC on the 
> last Saturday of March, and is to be applied to a zone in UTC+3, can 
> it represent the rule taking effect at 02:00 local on the Sunday 
> between 26 March and 1 April, inclusive?
>
>

I just cooked this up and tested my tzdata -> iCalendar generator:

# Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
Rule	XX	2014	max	-	Mar	lastSun	 23:00u	1:00	S
Rule	XX	2014	max	-	Oct	lastSun	 23:00u	0	-

Zone Test/Test	-3:26:56 -	LMT	1916 Jul 28 # Nuuk
			3:00	XX	X%sT

BEGIN:VCALENDAR
PRODID:-//CyrusIMAP.org//Cyrus git2.4.17-caldav-beta10+17//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Test/Test
LAST-MODIFIED:20140903T200017Z
X-LIC-LOCATION:Test/Test
BEGIN:STANDARD
TZOFFSETFROM:-032656
TZOFFSETTO:+0300
TZNAME:XT
DTSTART:19160728T000000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0300
TZOFFSETTO:+0400
TZNAME:XST
DTSTART:20140331T020000
RRULE:FREQ=YEARLY;BYYEARDAY=-275,-276,-277,-278,-279,-280,-281;BYDAY=MO
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0400
TZOFFSETTO:+0300
TZNAME:XT
DTSTART:20141027T030000
RRULE:FREQ=YEARLY;BYYEARDAY=-61,-62,-63,-64,-65,-66,-67;BYDAY=MO
END:STANDARD
END:VTIMEZONE
END:VCALENDAR

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 04 Sep 2014 14:27:38 +0200

> anyways, such as the 32-bit signed limit or something like

I don't like the idea of omitting TZEND. This could be like one brace 
missing from a pair of braces.

Would it be possible to use some special keyword like "UNDEF" or similar 
to specify that no end date for a rule has been determined, e.g. by 
legislation "until further notice"?

Martin

---

From: Arthur David Olson <[email-masked]>
Date: Thu, 4 Sep 2014 08:40:31 -0400

On the tzdb side, "maximum" (typically shortened to "max") is used;
"minimum" ("min") is used at the other end.

    @dashdashado