> Which APIs do you mean? I imagine it might be possible (note - just
> might be, no guarantees here) to get the system TZ data and use it in
> similar manner to existing TZ data if the formats are suitably close
> and all the info is available.
Yes, this is what I meant when I wrote about using /etc/localtime:
convert it into the same internal representation that PHP's own time zone
database uses and then just use the existing code as if /etc/localtime
was just another time zone in the database. However, this is definitely
not portable; at any rate Windows will not have /etc/localtime. Thus I
suggested that standard library functions be used:
> However if you mean using actual system functions in parallel with
> timelib functions, that's probably not going to happen - there's too
> many problems with using two APIs simultaneously to do the same thing,
> not talking about portability, etc.
Now that I think of it, the only system [library] calls that need to be
made are localtime() and mktime() to convert between timestamps and the
year-month-day-hour-min-sec representation, as these are the only
timezone-aware operations. And localtime() and mktime() are not just
POSIX but C89, so all platforms including Windows have them.
Even so, the Windows implementation is of course broken (it always uses
hard-coded DST rules and even seems to require TZ to be set), but doing
the same operations via the Win32 API is fairly easy. I had no knowledge
of this before and got this code just by looking at a couple of pages in
the MSDN Library:
SYSTEMTIME utc, local;
convert the timestamp into a SYSTEMTIME
SystemTimeToTzSpecificLocalTime(NULL, &utc, &local);
convert the resulting SYSTEMTIME into a struct tm
The reverse is similar. NULL means we want to use the current system time
zone. The format conversions are straightforward but take a few lines
each, which is why I omitted them. Funnily enough, the docs for
SystemTimeToTzSpecificLocalTime give a corner case in which the
conversion might be wrong, but (a) this is the same function that will
most likely be used by other Windows software and (b) this is the best we
can get, as I do not see any way to get the full time zone data with all
historical information in it.
> You seem to be misunderstanding what "portable" means here. It doesn't
> mean "compiles and runs on each system", it means "reliably produces
> predictable and identical results on each target system". The case with
> *time system functions is very far from that.
I think that in this case this is exactly not the best definition of
portable. What we really want (what I really want) from the System time
zone is that it compiles and runs on every system and on any particular
system works the same way as other software on the same system does.
Still, the only possible issue I see with portability in the traditional
sense is the range of timestamps that the *time functions work with,
which can be 'solved' by simply noting in the documentation that it is
platform-dependent (as it used to be solved when the *time functions were
used throughout).
--
Oleg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
