* break_iterator:
Fix typo in error message
BreakIterator: fix compat with old ICU versions
Fix build error one ext/intl
BreakIterator::getPartsIterator: new optional arg
Added IntlCodePointBreakIterator.
Add Intl prefix to BreakIterator/RuleBasedBI
Remove trailing space
Replaced zend_parse_method_params with plain zpp
BreakIter: Removed getAvailableLocales/getHashCode
Change in BreakIterator::getPartsIterator()
BreakIterator: add rules status constants
Tests for (RuleBased)BreakIterator.
BreakIterator and RuleBasedBreakiterator added
Can take one of:
* IntlPartsIterator::KEY_SEQUENTIAL (keys are 0, 1, ...)
* IntlPartsIterator::KEY_LEFT (keys are left boundaries)
* IntlPartsIterator::KEY_LEFT (keys are right boundaries)
The default is IntlPartsIterator::KEY_SEQUENTIAL (the previous behavior).
Objects of this class can be instantiated with
IntlBreakIterator::createCodePointInstance()
The method does not take a locale, as it would not make sense in this
context.
This class has one additional method:
long IntlCodePointIterator::getLastCodePoint()
which returns either -1 or the last code point we moved over, if any
(and discounting any movement before the last call to
IntlBreakIterator::first() or IntlBreakIterator::last()).
BreakIterator::getPartsIterator() now returns an IntlIterator subclass
with a special method, getBreakIterator(), that returns the
associated BreakIterator.
Any call to getRuleStatus() is forwarded to the BreakIterator.
By Gustavo André dos Santos Lopes (4) and others
via Felipe Pena (2) and Xinchen Hui (2)
* PHP-5.4:
Remove unused codes
based on microsoft's description,the direct convert from FILETIME struct to __int64 is unsafe.
merge 5.3 entries
restore NEWS
Fix ext/intl build on ICU < 4.8
Optimization in ext/intl/msgformat
Fixed tests in ext/intl
Changed XFAILed collator_get_sort_key.phpt
By Gustavo André dos Santos Lopes (4) and others
via Felipe Pena (1) and Xinchen Hui (1)
* PHP-5.3:
Remove unused codes
based on microsoft's description,the direct convert from FILETIME struct to __int64 is unsafe.
Fix ext/intl build on ICU < 4.8
Optimization in ext/intl/msgformat
Fixed tests in ext/intl
Changed XFAILed collator_get_sort_key.phpt
Ressurected and limited to ICU 4.8 in the hope that the sort keys
will remain stable in more recent ICU versions. I have only tested
with ICU 4.8 so far.
null is now accepted for two first (mandatory arguments).
Passing null as the package name causes NULL to be passed to ICU and
the default ICU data to be loaded.
Passing null as the locale name causes the default locale to be used.
Memory leak in IntlDateFormatter constructor.
udat_setCalendar() clones the calendar before it adopts it,
so we were leaking the original calendar.
Also we now validate the calendar type.
I don't think the current ICU API allows this bug to be completely fixed.
Right now, the code cannot control the time zone used in date/time formats
that appear inside complex subformats. See the comment inside
umsg_set_timezone().
IntlTimeZone::fromDateTimeZone(DateTimeZone $dtz) converts from an
ext/date TimeZone to an IntlTimeZone. The conversion is done by feeding
the time zone name (essentially what would be given by
DateTimeZone::getName()) to ICU's TimeZone::createTimeZone except if it's
an offset time zone. In that case, the offset is read from the ext/date
time zone object structure and an appopriate id (of the form
GMT<+|-><HH:MM>) is given to ICU's TimeZone::createTimeZone. Not all
ext/date time zones are recognized for ICU. For instance, WEST is not.
Note that these kind of abbreviations, as far as I can tell, can only be
created via ext/date DateTime, not directly through DateTimeZone's
constructor.
For IntlTimeZone::toDateTimeZone(), the behavior is symmetrical.
We instantiate a DateTimeZone and then call its constructor if we don't
have an offset time zone, otherwise we mess with its structure. If the
timezone is not valid for ext/date, then we allow the exception of
DateTimeZone constructor to propagate.
IntlCalendar::fromDateTime(DateTime|string $dateTime[, string $locale)
intlcal_from_date_time(...)
If a string is given as the first argument, the method will try to
instantiate a new DateTime object and use that instead.
MessageFormatter::parse and MessageFormat::format (and their static
equivalents) now don't throw away better than second precision in the
arguments.
It's already bad enough that in MessageFormatter and IntlDateFormatter we
use seconds since epoch instead of milliseconds since epoch, deviating
from the ICU date representations. But we don't need to throw away extra
precision when parsing dates; we can keep the seconds since epoch
convention and return non integer doubles with only a small BC impact.
Note that we already could return doubles from MessageFormatter::parse if
the date was sufficiently in the past or in the future.