> This can never be portable, because Windows doesn't even bother keeping > historical timezone rules. They only have: current normal UTC offset, > current DST offset and rules on when there is a transition between.
Windows does keep historical timezone rules and uses them in SystemTimeToTzSpecificLocalTime, although sadly not in localtime (I have just checked on Windows XP). In case you are interested, the historical rules are stored in the registry in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\*\Dynamic DST. > "System" is not a defined Timezone Identifier. So you can never match > this against anything else PHP does. My suggestion is exactly to define it. * timezone_name_get will return 'System'. * If an abbreviation is required at all times, an arbitrary one, say, 'SYS', will do. * timezone_offset_get will calculate the offset on the fly as described below. * timezone_location_get and timezone_transitions_get are indeed not implementable, but they are not implementable for, say, the existing Factory time zone either; they could just return the same nonsensical values they return for Factory, or some new special return values. Of course the return values should be documented in any case. > That'd mean duplicating every function that deals with timezone. As I > said: not going to happen. No, it is enough to make the new time zone TIMELIB_ZONETYPE_ID with no leap seconds and add a branch to fetch_timezone_offset: instead of enumerating the offsets in the time zone description, it will call localtime/SystemTimeToTzSpecificLocalTime, treat the result as UTC, convert it back to a timestamp and subtract from it the original timestamp. On systems with tm_gmtoff in struct tm, it can be used as a shortcut. On UNIX, the DST status can be obtained from the tm_isdst member of struct tm and an abbreviation can be obtained from the tm_zone member or the tzname global variable. On Windows, more work is needed but ultimately both can obtained from GetTimeZoneInformationForYear. I have tried and failed to understand the in_transition logic in do_adjust_timezone, so that, or rather timelib_update_ts, may (or may not) need new code as well, but all other functions will work perfectly well with no changes. - Finally, while I was writing this and investigating the code, I noticed that strtotime does some obscure timezone-dependent preprocessing of its $now argument. Is this intended? -- Oleg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
