Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60211
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: "Stas Malyshev" <smalyshev@sugarcrm.com>
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>
 <4F8F37F8.8020308@sugarcrm.com>
Date: Thu, 19 Apr 2012 09:53:27 +0200
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_I=2ES=2ET=2E?=
Message-ID: <op.wcz5jdkaidpuyk@slws007.slhq.int>
In-Reply-To: <4F8F37F8.8020308@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 Wed, 18 Apr 2012 23:54:00 +0200, Stas Malyshev <smalyshev@sugarcrm.com>  
wrote:

>> 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.

It's ICU docs, but they're applicable here after doing the obvious  
substitutions (replace all integer types with PHP's integer, etc.).
You can list the functions with php --rc IntlCalendar or similar and then  
refer to that document for the functions' behavior. Of course, this  
doesn't replace PHP documentation, but it's not urgent at this stage given  
PHP 5.5 being one year away and the ICU docs giving almost all information  
to those who want to play with it.

>> 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?

"UDate is a scalar value that indicates a specific point in time,  
independent of calendar system and local time zone. It is stored as the  
number of milliseconds from a reference point known as the epoch. The  
epoch is midnight Universal Time Coordinated (UTC) January 1, 1970 A.D.  
Negative UDate values indicate times before the epoch."  
(http://userguide.icu-project.org/datetime#TOC-How-ICU-Represents-Dates-Times  
)

UDate is just a typedef for double, and is represented in PHP with the  
float type.

As for DateTime, IntlGregorianCalendar (a specific type of IntlCalendar)  
*DOES* duplicate some functionality of DateTime. There are some things  
DateTime does that IntlGregorianCalendar doesn't (like formatting and  
parsing, which is done in intl through IntlDateFormatter) and there are  
things that IntlGregorianCalendar does that DateTime doesn't (refer to my  
previous e-mails on this thread).

I'm working on some interoperability with the two; see  
https://github.com/cataphract/php-src/commit/e6c4dc8

>> 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.

Patches welcome :) More seriously, adding complete support for time zones  
is time consuming because it implies also supporting the classes with  
which the subclasses of TimeZone collaborate -- for instance, the several  
types of DST rules. Maybe it's possible to work around that without  
compromising having full support in the future -- I'm happy to hear ideas.

>> 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)?

Again, I'm working on that:  
https://github.com/cataphract/php-src/commit/361cf32

I'll post something to this list for review when I have something ready.

-- 
Gustavo Lopes