Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59321 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 40071 invoked from network); 2 Apr 2012 10:07:33 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Apr 2012 10:07:33 -0000 Authentication-Results: pb1.pair.com smtp.mail=glopes@nebm.ist.utl.pt; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=glopes@nebm.ist.utl.pt; sender-id=unknown Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.22 cause and error) X-PHP-List-Original-Sender: glopes@nebm.ist.utl.pt X-Host-Fingerprint: 193.136.128.22 smtp2.ist.utl.pt Linux 2.6 Received: from [193.136.128.22] ([193.136.128.22:33987] helo=smtp2.ist.utl.pt) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B9/3D-02210-46A797F4 for ; Mon, 02 Apr 2012 06:07:32 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.ist.utl.pt (Postfix) with ESMTP id 6ABEB70004D0; Mon, 2 Apr 2012 11:07:28 +0100 (WEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at ist.utl.pt Received: from smtp2.ist.utl.pt ([127.0.0.1]) by localhost (smtp2.ist.utl.pt [127.0.0.1]) (amavisd-new, port 10025) with LMTP id tm8TwbrPVmYZ; Mon, 2 Apr 2012 11:07:28 +0100 (WEST) Received: from mail2.ist.utl.pt (mail.ist.utl.pt [IPv6:2001:690:2100:1::8]) by smtp2.ist.utl.pt (Postfix) with ESMTP id 0A09570003FA; Mon, 2 Apr 2012 11:07:28 +0100 (WEST) Received: from slws007.slhq.int (a79-168-248-114.cpe.netcabo.pt [79.168.248.114]) (Authenticated sender: ist155741) by mail2.ist.utl.pt (Postfix) with ESMTPSA id 3EF142023234; Mon, 2 Apr 2012 11:07:27 +0100 (WEST) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: =?utf-8?Q?Johannes_Schl=C3=BCter?= , "Derick Rethans" Cc: "internals@lists.php.net" , "Stas Malyshev" References: <1333359444.10466.2.camel@guybrush> Date: Mon, 02 Apr 2012 12:07:23 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?= =?utf-8?Q?ca_do_I=2ES=2ET=2E?= Message-ID: In-Reply-To: User-Agent: Opera Mail/11.61 (Win32) Subject: Re: [PHP-DEV] Addition of calendar to intl From: glopes@nebm.ist.utl.pt ("Gustavo Lopes") On Mon, 02 Apr 2012 11:44:17 +0200, Derick Rethans wrot= e: > On Mon, 2 Apr 2012, Johannes Schl=C3=BCter wrote: >> Basically it is good to have those calender stuff available. I wonder= >> how this relates to our datelib. Can this somehow be integrated, at >> least for Gregorian calender times, so one can easily convert from on= e >> to the other etc.? Ideally we'd just have one API :-) We could surely add functions that convert between DateTime and = IntlCalendar objects (there would be some issues on how tightly the time= = zones could be integrated; see below). But to have one API is basically = = near impossible given that PHP does not depend itself on ICU. > Sadly, when I looked at it last time, the ICU stuff insistent on havin= g > a timestamp only as input to their formatting functionality :-/ We'd > need to use a few things on the ext/date side to get ICU locale > formatting into the date/time stuff. > This is not about formatting. This is about these kind of date = calculations: * converting timestamps to dates and vice-versa (but not in a human = readable fashion, locales affect only the calendar type and minor stuff = = like when the week or weekend start; you get the date fields by method = calls such as $cal->get(IntlCalendar::FIELD_HOUR_OF_DAY)). * Adding and rolling amounts to fields. * Calculating field differences. * Determine weekend onsets and offsets. The formatting and parsing of dates is done with IntlDateFormatter, whic= h = accepts DateTime objects, though this "integration" with the date = extension could possibly be improved. Going a bit off-topic: I think the problem you have with datefmt_format is that the time zone i= s = specified through the formatter and the one of DateTime is ignored. One = = could add a new function that creates a formatter with the correct time = = zone extracted from DateTime, but there's still the problem that ICU = cannot use PHP's time zone objects directly, so we'd have to use the = identifiers. It could be possible to subclass ICU's TimeZone class to = create a ICU TimeZone that would wrap a DateTimeZone, but it would also = = imply using the C++ API for IntlDateFormatter, which is not the case = currently. -- = Gustavo Lopes