Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59457
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.21 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: internals@lists.php.net, "Stas Malyshev" <smalyshev@sugarcrm.com>
References: <op.wb4p5lxsidpuyk@slws007.slhq.int>
 <4F80DE16.1020407@sugarcrm.com>
Date: Sun, 08 Apr 2012 14:01:42 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_IST?=
Message-ID: <op.wcf6g4rbidpuyk@cataphract.cata.lo.geleia.net>
In-Reply-To: <4F80DE16.1020407@sugarcrm.com>
User-Agent: Opera Mail/11.62 (Win32)
Subject: Re: Addition of calendar to intl
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

On Sun, 08 Apr 2012 01:38:46 +0100, Stas Malyshev <smalyshev@sugarcrm.com>  
wrote:

>> http://icu-project.org/apiref/icu4c/classCalendar.html
>
> I hope the times of "commit huge patches first, discuss them and
> document later if ever" are behind us. Or at least we should try to put
> them behind us.

I think the documentation part in this case is not as problematic, because  
the interface has been thoroughly documented in the ICU project. Most of  
your next questions can be answered by reading

http://userguide.icu-project.org/datetime/calendar

> As for the API, I'm not sure I understand properly what it is supposed
> to do (one of the downsides of no RFC). Is it for date calculations?
> What kinds of calculations you could do?

See http://userguide.icu-project.org/datetime/calendar#TOC-Usage

> What is IntlGregorianCalendar
> class - and why there is Gregorian one, but not others?

Because the other type calendars, while existing and been implemented as  
separate C++ classes in ICU, are not part of the ICU public API. You are  
supposed to instantiate them through a factory method and use only the  
generic operations defined in Calendar. GregorianCalendar is the only  
public subclass. You can instantiate it directly and use specific methods  
-- get/setGregorianChange (to change the Julian/Gregorian cutoff date) and  
isLeapYear.

> If I wanted to work with Hebrew calendar, how would I do that?

By specifying @calendar=hebrew in the locale (either in  
intl.default_locale or by passing it to the factory method  
IntlCalendar::createInstance()).

> What does it do that DateTime doesn't?

Asides from supporting many more types of calendars, it has millisecond  
precision (for dates not too back into the past or future), field rolling,  
more control on behavior in DST transitions (since ICU 49) and some  
localization options (e.g. localized day of week).

> For the timezones - what is the difference between these timezones and
> the ones DatTime has - is there something additional that these provide?

The main drive for creating a IntlTimeZone class was simply to  
encapsulate  ICU TimeZone objects, which the Calendar classes work with.  
Therefore, the support is limited and only the base ICU class for  
timezones is exposed, except for the methods that allow changing the  
TimeZone. ICU allows you to build timezones with arbitrary rules,  
import/export RFC2445 VTIMEZONE and a lot more, none of which are  
available with my patch.

Still, there is already some functionality that doesn't exist in  
DateTimeZone, like timezone id canonization, localization of time zone  
names on 8 different formats and easier searching for timezones according  
to country and region.

-- 
Gustavo Lopes