Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60205
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.113 as permitted sender)
Message-ID: <4F8F37F8.8020308@sugarcrm.com>
Date: Wed, 18 Apr 2012 14:54:00 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Gustavo Lopes <glopes@nebm.ist.utl.pt>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <op.wb4p5lxsidpuyk@slws007.slhq.int> <4F80DE16.1020407@sugarcrm.com> <op.wcf6g4rbidpuyk@cataphract.cata.lo.geleia.net>
In-Reply-To: <op.wcf6g4rbidpuyk@cataphract.cata.lo.geleia.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: Addition of calendar to intl
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> 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

This is ICU docs, not PHP docs. Most PHP users wouldn't even know where
to find it, let alone how to use it applied to PHP. We need something to
list the functions and what they do. RFC can serve this role, until
proper docs are written, but since you've skipped it, we need some other
solution, but without that it will be hard to make use of it effectively.

> See http://userguide.icu-project.org/datetime/calendar#TOC-Usage

OK, I see but it refers to UDate and operations with it - does it
duplicate what we do with DateTime? What would be typical use case - to
use DateTime or your calendar functions? Would I have to keep dates in
two separate forms? How this interacts with DateTime?

> By specifying @calendar=hebrew in the locale (either in 
> intl.default_locale or by passing it to the factory method 
> IntlCalendar::createInstance()).

That definitely has to be documented somewhere.

> 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.

I'd say if we already have this class why not support at least most
useful things? I'd find VTIMEZONE support definitely very useful.

> 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.

Is there an easy way to get from DateTimeZone to intl one and back (at
least for standard ones, custom ones probably won't work)?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227