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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
