Hi! > This is not correct. Some functions in IntlCalendar also use this > direct representation of UDate, see e.g. > > http://pt2.php.net/manual/en/intlcalendar.getnow.php > http://pt2.php.net/manual/en/intlcalendar.gettime.php
OK, I see. > As far as I know, there's not any strictly technical reason to prefer > working milliseconds rather than seconds short of saving some arithmetic > operations before passing the values to ICU -- I don't think the > rounding error introduced by dividing by 1000 is relevant for the sort > of dates one is likely to work with. I take no position on whether I am just surprised we have an API that works differently from all other APIs in PHP, and for what seems to be not better reason that compatibility with internal representation of the library (which we don't preserve in many other cases). Re-reading the mail thread back when it was merged, I recall now I was surprised by that back then too. Could we at least have some documentation for it so that it could be clear what's going on and how these functions go together? Since we had no RFC for this functionality at all, and still no docs except for skeletal ones more than a year after merge, it makes it really hard to understand what's going on. -- 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
