ID:               49609
 User updated by:  jo at feuersee dot de
 Reported By:      jo at feuersee dot de
 Status:           Open
 Bug Type:         Feature/Change Request
 Operating System: *
 PHP Version:      5.3.0
 New Comment:

date_parse() and the proposed equivalent to ICU DateFormat::parse() (or
the existing IntlDateFormatter::localtime() ) do have totally different
intentions and functionality.

date_parse() returns a datetime struct from a strtotime() compatible
string.

DateFormat::parse() parses a _localized_ date/time string into a
portable Object (UDate) which is equivalent to PHP DateTime.
Localized date/time are _not_ strtotime() compatible, could be a string
with a localized date/time like
de_DE: "Sonntag, 20. September 2009"
ja_JP: "2009年9月21日 04:38:29JST"

Just take a look of the ICU API:
<http://icu-project.org/apiref/icu4c/classDateFormat.html>

Replace the C++ UDate class with DateTime and this is pretty much how
the PHP class should look like - no reason to invent another PHPish
wheel...

And I really don't want to work on silly structured hashes, I want my
PHP to be object oriented.


Previous Comments:
------------------------------------------------------------------------

[2009-09-20 19:07:10] der...@php.net

There is a date_parse() already: http://uk.php.net/date_parse

------------------------------------------------------------------------

[2009-09-20 18:58:04] jo at feuersee dot de

I might add the request for a method parse($string) which works like
the localtime() method but returns a DateTime object (or at least a
DateTime (ISO 8601) parseable string. Like the DateFormat of ICU does.

The struct returned by localtime() is really impractical to handle (eg.
tm_mon is numbered 0-11, tm_year is defined as "years since 1900").

------------------------------------------------------------------------

[2009-09-20 14:39:43] jo at feuersee dot de

Description:
------------
The usage of the ICU based IntlDateFormatter class would be much more
convenient if it would support DateTime objects, especially the format()
method.

The workaround is to parse the DateTime value to a timestamp and cast
it to int (or use getTimestamp() with PHP 5.3.0+).

The alternative localtime() structured param is a bit odd IMHO, I
really can't remember having seen any usage of this function in the last
10 years. It seems it has been chosen to circumvent the limited range of
timestamps?
In fact, the range of localtime() is limited, though not as much as
mktime():
with Linux on x686 it's approx. from UTC 1902-01-01 to 2038-01-19

The DateTime class does not have this limited range, a nice OO design,
works great with ISO 8601 formatted dates and times . why not use it in
IntlDateFormatter?


Reproduce code:
---------------
1) php -r '$fmt = new IntlDateFormatter("de_DE"
,IntlDateFormatter::MEDIUM, IntlDateFormatter::MEDIUM, "UTC"); 
$dt = new DateTime("1781-12-13"); 
printf("%s\n", $fmt->format($dt));'

2) php -r '$fmt = new IntlDateFormatter("de_DE"
,IntlDateFormatter::MEDIUM, IntlDateFormatter::MEDIUM, "UTC"); 
$dt = new DateTime("1781-12-13"); 
printf("%s\n", $fmt->format($dt->format("U")));'

3) php -r '$fmt = new IntlDateFormatter("de_DE"
,IntlDateFormatter::MEDIUM, IntlDateFormatter::MEDIUM, "UTC"); 
$dt = new DateTime("1781-12-13"); 
printf("%s\n", $fmt->format((int) $dt->format("U")));'



Expected result:
----------------
1) 12.12.1781 23:00:00

2) 12.12.1781 23:00:00

3) 12.12.1781 23:00:00



Actual result:
--------------
1)

2) 

3) 12.12.1781 23:00:00


------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=49609&edit=1

Reply via email to