Subject: Re: [Tzdist] Comments on timezone-service-11 sections 1 thru 4

From: Ken Murchison <[email-masked]>
Date: Mon, 15 Sep 2014 13:47:59 -0400

On 08/20/2014 07:00 PM, Paul Eggert wrote:
>
> E.  Section 3.4 talks about truncation as if it applied only to past 
> data, but it also applies to the future.  For example, the tz database 
> currently truncates the data for "Asia/Tehran" after 2037, because 
> Iran's actual rules are based on the Persian calendar and cannot be 
> expressed compactly in tz format (or in VTIMEZONE format, I presume). 
> Worse, some rules are based on astronomical calendars and therefore 
> cannot be predicted into the indefinite future.

Hi Paul,

Just as an FYI, the Asia/Tehran rules could be compactly represented in 
VTIMEZONE using the RSCALE 
<http://tools.ietf.org/html/draft-daboo-icalendar-rscale> extension as 
below (RSCALE should be adopted by the CalExt WG shortly).  That being 
said, I don't think any automated tz data -> iCal converter (e.g. vzic) 
could generate this from the tz data as currently constituted unless it 
could parse and act upon the meta-data in the comments.

BEGIN:DAYLIGHT
TZNAME:IRDT
TZOFFSETFROM:+0330
TZOFFSETTO:+0430
DTSTART:19920322T000000
RRULE:RSCALE=PERSIAN;FREQ=YEARLY;BYMONTH=1;BYMONTHDAY=2
END:DAYLIGHT

BEGIN:STANDARD
TZNAME:IRST
TZOFFSETFROM:+0430
TZOFFSETTO:+0330
DTSTART:19910922T000000
RRULE:RSCALE=PERSIAN;FREQ=YEARLY;BYMONTH=6;BYMONTHDAY=31
END:STANDARD

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Paul Eggert <[email-masked]>
Date: Mon, 15 Sep 2014 11:06:04 -0700

On 09/15/2014 10:47 AM, Ken Murchison wrote:
> Just as an FYI, the Asia/Tehran rules could be compactly represented 
> in VTIMEZONE using the RSCALE 
> <http://tools.ietf.org/html/draft-daboo-icalendar-rscale>extension as 
> below (RSCALE should be adopted by the CalExt WG shortly).

Interesting.  My understanding, though, is that the official calendar 
used in Iran is astronomical and not arithmetic, which means 
RSCALE=PERSIAN cannot be implemented stably into the indefinite future, 
as the exact dates will depend on when sunrise is actually observed.  
Although astronomical predictions are reasonably accurate, the current 
predictions are at least somewhat in question for the Gregorian years 
2025, 2058, 2091, 2157, and no doubt other years.  Please see the 
comments in the 'asia' file for details.

Or is it the intent that RSCALE=PERSIAN means "we don't know exactly how 
to convert future dates to Gregorian yet, but we'll give you a guess"?  
If so, I hope that's stated clearly in the spec, and I expect libraries 
and applications will need some advice as to how to deal with that sort 
of thing, e.g., what to do when different implementations make different 
guesses.

---

From: Ken Murchison <[email-masked]>
Date: Mon, 15 Sep 2014 14:15:02 -0400

On 09/15/2014 02:06 PM, Paul Eggert wrote:
> RSCALE=PERSIAN cannot be implemented stably into the indefinite 
> future, as the exact dates will depend on when sunrise is actually 
> observed.  Although astronomical predictions are reasonably accurate, 
> the current predictions are at least somewhat in question for the 
> Gregorian years 2025, 2058, 2091, 2157, and no doubt other years.  
> Please see the comments in the 'asia' file for details.
>
> Or is it the intent that RSCALE=PERSIAN means "we don't know exactly 
> how to convert future dates to Gregorian yet, but we'll give you a 
> guess"?  If so, I hope that's stated clearly in the spec, and I expect 
> libraries and applications will need some advice as to how to deal 
> with that sort of thing, e.g., what to do when different 
> implementations make different guesses.

In my case, I've implemented RSCALE using the ICU 
<http://site.icu-project.org/> library, so I'd have to dig into the docs 
and/or code to see how they actually implement the Persian calendar.