# Local time zone

- Thread: https://externals.io/message/56866
- Original archive: https://news-web.php.net/php.internals/56866
- Started by Oleg Oshmyan on 2011-12-11T00:59:45+00:00
- Messages: 36
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/56866.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #56866 — Oleg Oshmyan — 2011-12-11T00:59:45+00:00

URL: https://externals.io/message/56866#56866

PHP is used for server-side software that needs to use the remote
client's time zone and for distributed software potentially running on
geographically dispersed servers that needs to use a common time zone,
and in these cases there is no doubt that the time zone should be
manually specified and that the default should be universally constant if
it exists at all. However, PHP is also used for utilities that people run
on their personal machines, and in most cases they _want_ to use the
current system time zone, whatever it is. PHP 5.3 provides a way
to at least guess the current system time zone:

    date_default_timezone_set(@date_default_timezone_get());

PHP 5.4, as currently planned, removes this ability and does not add any
other way to get the system time zone. First, let me ask: is this right
or does another way exist? Second, if no other way exists, I urge that
the guessing algorithm is added back in or split out into a separate
function, say, date_system_timezone_get. Third, I propose improvements
to the guessing algorithm on UNIX:

* The tzname C variable can be used to get two abbreviations for the
  current zone (typically the standard one and the DST one for zones
  where DST is used), which allows to improve the guess compared to using
  just one abbreviation; for example, the time zone in London in winter
  will be guessed as Europe/London rather than UTC.

* /etc/localtime is often a symbolic link to or a copy of
  /usr/share/zoneinfo/<time zone identifier>. In this case this time zone
  identifier can be considered another candidate just like the values
  of date.timezone and TZ.

* This requires more effort, but ideally PHP should just have a special
  time zone named something like 'System' that would use /etc/localtime
  instead of any built-in time zone data, just like the localtime
  C function does when the TZ environment variable is empty.

I am willing to work on patches but I suppose some consensus should be
reached first.

-- 
Oleg

---

## #56869 — Pierre Joye — 2011-12-11T12:07:47+00:00

URL: https://externals.io/message/56866#56869 · In reply to: #56866

hi,



> I am willing to work on patches but I suppose some consensus should be
> reached first.

The consensus was that you have to set a valid default timezone in php.ini

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

---

## #56883 — Derick Rethans — 2011-12-12T11:36:22+00:00

URL: https://externals.io/message/56866#56883 · In reply to: #56866

> * The tzname C variable can be used to get two abbreviations for the
>   current zone (typically the standard one and the DST one for zones
>   where DST is used), which allows to improve the guess compared to using
>   just one abbreviation; for example, the time zone in London in winter
>   will be guessed as Europe/London rather than UTC.

It's a guess, and that's the problem. Guessing makes up for odd and 
strange bugs if it's not 100% accurate (which it isn't). 

> * /etc/localtime is often a symbolic link to or a copy of
>   /usr/share/zoneinfo/<time zone identifier>. In this case this time zone
>   identifier can be considered another candidate just like the values
>   of date.timezone and TZ.

This might work on some distrbutions, but not nearly on all. And 
definitely not on Windows. On Debian it's not a symlink for example.

> * This requires more effort, but ideally PHP should just have a special
>   time zone named something like 'System' that would use /etc/localtime
>   instead of any built-in time zone data, just like the localtime
>   C function does when the TZ environment variable is empty.

That's a really bad idea, as we've discussed before on this list.

cheers,
Derick

---

## #56884 — Evert Pot — 2011-12-12T13:30:32+00:00

URL: https://externals.io/message/56866#56884 · In reply to: #56869

> hi,
> 
> 
> 
> > […]
> 
> The consensus was that you have to set a valid default timezone in php.ini

I feel there may be a lot of value for people being able to install PHP applications and run them without any additional configuration.

What would be the recommended way to have PHP reflect the systems timezone?

I like the PHP 5.4.0 behaviour of defaulting to UTC if it's not setup, but would it be possible to get the old functionality through a warning-less 'date_guess_system_timezone'. 

The 'guess' in the function-name should be enough of a warning. People who opt-in to this behaviour explicitly comply to the possible inaccuracy of the result. I would be one of those people, and as much as it may disturb you; I feel I'm not alone.

Evert

---

## #56886 — Pierre Joye — 2011-12-12T14:00:05+00:00

URL: https://externals.io/message/56866#56886 · In reply to: #56884

hi,



> The 'guess' in the function-name should be enough of a warning. People who opt-in to this behaviour explicitly comply to the possible inaccuracy of the result. I would be one of those people, and as much as it may disturb you; I feel I'm not alone.

It is totally unreliable and has caused so many troubles (and consumed
many of our debugging time). See this ML archive for the various
discussions, or bugs.php.net.

I do not think it is too much asking to an admin to setup the correct
default timezone in php.ini on install, or to allow users to set it
for their virtual hosts via the usual interface.

In short, the amount of troubles on our side (support) is not worth
it, in comparison to what it takes to have a sane setup.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

---

## #56889 — Derick Rethans — 2011-12-12T14:34:24+00:00

URL: https://externals.io/message/56866#56889 · In reply to: #56884

> 
> 
> > […]
> 
> I feel there may be a lot of value for people being able to install 
> PHP applications and run them without any additional configuration.
> 
> What would be the recommended way to have PHP reflect the systems 
> timezone?

The best way is always going to be: set it up yourself.

> I like the PHP 5.4.0 behaviour of defaulting to UTC if it's not setup, 
> but would it be possible to get the old functionality through a 
> warning-less 'date_guess_system_timezone'.
> 
> The 'guess' in the function-name should be enough of a warning. People 
> who opt-in to this behaviour explicitly comply to the possible 
> inaccuracy of the result. I would be one of those people, and as much 
> as it may disturb you; I feel I'm not alone.

The extension already has 
http://uk3.php.net/manual/en/function.timezone-name-from-abbr.php
which is basically the guessing algorithm.

cheers,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

---

## #56891 — Oleg Oshmyan — 2011-12-12T15:00:40+00:00

URL: https://externals.io/message/56866#56891 · In reply to: #56886

> I do not think it is too much asking to an admin to setup the correct
> default timezone in php.ini on install, or to allow users to set it for
> their virtual hosts via the usual interface.

We are not talking only about servers here. We are mainly talking about
personal machines, including laptops of people who travel often. Of
course it is possible to just say that whenever one changes the system
time zone, one should also change the time zone in php.ini. But that
becomes tedious, and if PHP's guessing algorithm works for some people,
why not let them use it?

> It is totally unreliable and has caused so many troubles (and consumed
> many of our debugging time).

I have proposed a couple of improvements, in particular one that could
resolve some DST issues (using tzname to get two abbreviation hints). And
by making it even more explicit that the algorithm performs but a guess,
for example, by moving it to a function with 'guess' in the function
name, bug reports of the sort 'the guess is wrong' can be given a very
low priority if not closed right away. Finally, the unreliability of the
guessing algorithm is exactly why I proposed using system-provided local
time descriptions/APIs.

This issue boils down to: people want software to behave the same way
whichever language it is written in. Things written in Bourne shell,
cmd.exe, C, Perl, Python, Ruby all use the system time zone, or at least
that which was the system time zone when the program made its first call
to a function like localtime. Even MySQL has a time zone called SYSTEM
and uses it by default. PHP is the odd man out: not only does it not use
the system time zone by default, as it instead tries to find one in its
own time zone database that seems most similar, but it is also going to
remove the only ready way to get any close to getting the system time
zone in the next release.

-- 
Oleg

---

## #56892 — Oleg Oshmyan — 2011-12-12T17:33:22+00:00

URL: https://externals.io/message/56866#56892 · In reply to: #56883

> This might work on some distrbutions, but not nearly on all. And 
> definitely not on Windows. On Debian it's not a symlink for example.

It is still usable as one of the possibilities for the guessing algorithm
to examine.

Initially I also wanted to say that /usr/share/zoneinfo can be searched
if /etc/localinfo is not a symbolic link, but I have just run a test:

    time { find /usr/share/zoneinfo -type f \
           -exec cmp -s /etc/localtime '{}' \; -print; }

and it took 1.5 seconds on openSUSE 11.4 and a second on Mac OS X 10.6
(by the way, on the latter /etc/localtime is a symbolic link). I suppose
it would take less if I only examined paths corresponding to time zones
known to PHP but it would likely still take a long time. Thus this is
perhaps reasonable as optional behaviour (such as
date_system_timezone_guess($try_harder=false) called with true as the
argument) but certainly unwanted in code that executes by default.

> It's a guess, and that's the problem. Guessing makes up for odd and 
> strange bugs if it's not 100% accurate (which it isn't). 

Which is why a pseudo-timezone called System is needed so that guesses do
not have to be made. The extension would then convert /etc/localtime to
its internal time zone description format or just use system-provided
APIs as it used to do before PHP 5.1 if I understand correctly.

> That's a really bad idea, as we've discussed before on this list.

I can see why it is a bad idea to make such a time zone the default in a
language used mostly for server-side software, although replacing it with
a guess approximating such a time zone as the default, which is what PHP
5.1 did, seems even worse, and it is good to see that PHP 5.4 takes a
better approach. However, I do not see how this is a bad idea for scripts
people run among other software that all uses the system time zone--or
perhaps I should even say 'the system's notion of local time', since
(however uncommon this is) it might be different from any particular time
zone. I have searched in the archive of php-internals and not found any
discussion of this. Perhaps I am a bad searcher; I would appreciate if
you pointed me at some of the past discussion.

-- 
Oleg

---

## #56911 — Derick Rethans — 2011-12-13T14:48:14+00:00

URL: https://externals.io/message/56866#56911 · In reply to: #56892

> > […]
> 
> It is still usable as one of the possibilities for the guessing algorithm
> to examine.
> 
> Initially I also wanted to say that /usr/share/zoneinfo can be searched
> if /etc/localinfo is not a symbolic link, but I have just run a test:

<snip>

We will not be adding code that has to scan the filesystem.

> > […]
> 
> Which is why a pseudo-timezone called System is needed so that guesses do
> not have to be made. The extension would then convert /etc/localtime to
> its internal time zone description format or just use system-provided
> APIs as it used to do before PHP 5.1 if I understand correctly.
> 
> > […]

<snip>

> Perhaps I am a bad searcher; I would appreciate if you pointed me at 
> some of the past discussion.

http://marc.info/?t=119988823700001&r=1&w=2 is what it was I think.

cheers,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

---

## #56915 — Oleg Oshmyan — 2011-12-13T19:09:21+00:00

URL: https://externals.io/message/56866#56915 · In reply to: #56911

> > […]
> 
> <snip>
> 
> > […]
> 
> http://marc.info/?t=119988823700001&r=1&w=2 is what it was I think.

Thanks. The thread was an interesting read but my suggestion is different
from the one discussed there: I propose adding _one_ special time zone
that will use the /etc/localtime file or system-provided APIs (only that
time zone!), not using the /usr/share/zoneinfo directory instead of the
built-in time zone database. So existing code would work just as before
but in addition one could write

    date_default_timezone_set('System');

and get direct access to the system's own notion of local time, so e. g.

    date_default_timezone_set('System');
    echo date('r');

would be equivalent to the C code

    char date[256];
    time_t now = time(NULL);
    strftime(date, 256, "%a, %d %b %Y %H:%M:%S %z", localtime(&now));
    fputs(date, stdout);

While PHP does focus on server-side Web programming, it is not limited to
it and is a general-purpose scripting language. It can be used to run
'client-side' scripts just like the shell, Perl, Python and Ruby can be
used, and in fact it can also be similarly used to run command-line (or
even graphical) utilities on servers, and even in Web pages one might
sometimes explicitly want to use the server time. In all these cases
system time needs to be used, and the only reliable way to do so is to
refer directly to the local time zone description and/or local time APIs
provided by the system. Being independent of the system in other cases is
also important, and so adding a single special time zone that trusts the
system to the already-existing set of time zones that do not trust the
system seems not just a compromise but a win-win solution.

For now I will find where all my php.ini files are, add date.timezone and
write a script to edit them all at once when I move from one time zone to
another. I might even schedule it to run regularly and pick up changes
automatically or even make it a daemon if I was constantly travelling.
This will normally work for me even if it somewhat annoys me, but if I
forget to run my script or if I decide for any reason to move to (or
pretend I am in) some obscure time zone PHP does not know, I will easily
be able to explain that to my system, including virtually all other
software I use, but not to PHP.

Recommending server administrators to set date.timezone to provide
scripts with the ability of using the server's local time also has a
negative consequence: poorly-written software that uses local time
without caring about time zones will stop generating the warnings it
generates now. In the end this might well encourage such poor practices
more than discourage them.

Finally, a word on removing support for the TZ environment variable in
particular: once again this makes good sense for server-side software but
is bad for client-side software, as TZ is a standard way of telling
software you launch which time zone you want it to work in. When the
local time API used by this software supports TZ (and just about
everything supports it), it just works, without the programmer doing
further work such as adding command-line options and in fact without them
even knowing that you use this functionality. For example, I have used
this to make commits on a remote machine (in an SSH session) with commit
dates recording my local time zone instead of the (properly used!) system
time zone of the remote machine.

-- 
Oleg

---

## #56917 — Derick Rethans — 2011-12-14T10:26:08+00:00

URL: https://externals.io/message/56866#56917 · In reply to: #56915

> > […]
> 
> Thanks. The thread was an interesting read but my suggestion is different
> from the one discussed there: I propose adding _one_ special time zone
> that will use the /etc/localtime file or system-provided APIs (only that
> time zone!), not using the /usr/share/zoneinfo directory instead of the
> built-in time zone database. So existing code would work just as before
> but in addition one could write

I suggest you lobby distributions that bundle PHP to add a post-install 
script for "dpkg-reconfigure tzdata" to drop a datetime.ini file in 
/etc/php5/conf.d with as contents "date.timezone=<newly selected 
timezone>". Using the information from /etc/localtime is *not* enough as 
you can't get the timezone identifier out of it.


>     date_default_timezone_set('System');
> 
> and get direct access to the system's own notion of local time, so e. g.
> 
>     date_default_timezone_set('System');
>     echo date('r');
> 
> would be equivalent to the C code
> 
>     char date[256];
>     time_t now = time(NULL);
>     strftime(date, 256, "%a, %d %b %Y %H:%M:%S %z", localtime(&now));
>     fputs(date, stdout);

That will never happen. The whole idea with the new support is to get 
*away* from OS idiosyncrasies and not adding more of them! PHP needs to 
be able to rely on its own bundled timezone database. Parsing files on 
the filesystem is slow and silly.

> Finally, a word on removing support for the TZ environment variable in
> particular: once again this makes good sense for server-side software but
> is bad for client-side software, as TZ is a standard way of telling
> software you launch which time zone you want it to work in.

TZ key values are not identical among operating systems, so that doesn't 
work.

cheers,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

---

## #56918 — Pierre Joye — 2011-12-14T10:33:31+00:00

URL: https://externals.io/message/56866#56918 · In reply to: #56917

> That will never happen. The whole idea with the new support is to get
> *away* from OS idiosyncrasies and not adding more of them! PHP needs to
> be able to rely on its own bundled timezone database. Parsing files on
> the filesystem is slow and silly.

And last but not least, it is not portable at all.

-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

---

## #56921 — Oleg Oshmyan — 2011-12-14T18:24:14+00:00

URL: https://externals.io/message/56866#56921 · In reply to: #56917

> I suggest you lobby distributions that bundle PHP to add a post-install 
> script for "dpkg-reconfigure tzdata" to drop a datetime.ini file in 
> /etc/php5/conf.d with as contents "date.timezone=<newly selected 
> timezone>".

This is a good idea (or perhaps exactly the opposite, as I explained in my previous email, but still needed if PHP drops all and any support for system-provided local time), but sometimes people use local copies of PHP instead of system-wide ones or their systems do not come with PHP at all.

> Using the information from /etc/localtime is *not* enough as 
> you can't get the timezone identifier out of it.

The time zone identifier would be System. No need to extract one from /etc/localtime.

> That will never happen. The whole idea with the new support is to get 
> *away* from OS idiosyncrasies and not adding more of them! PHP needs to 
> be able to rely on its own bundled timezone database. Parsing files on 
> the filesystem is slow and silly.

Why is it bad to have this as added functionality? Why are you worried about PHP's ability to rely on its own bundled time zone database? Let me explain my idea once again:

I propose **leaving all existing functionality alone** and **adding a new time zone** called System.

* All existing time zones will work as they do in PHP 5.4 RC3. The internal time zone database will be used, the internal timezone-aware code will be used and the system will not be consulted at all. Any PHP code using existing time zones will remain perfectly portable across all PHP installations.

* date_default_timezone_get will work as it does in PHP 5.4 RC3. Perhaps there is confusion because I initially proposed restoring the guessing algorithm, so let me make this clear: this is a separate suggestion. So, once again: date_default_timezone_get will work as it does in PHP 5.4 RC3.

* There will be a new time zone called System. When this time zone is active, instead of PHP's internal time zone database and timezone-aware code, system-provided local time APIs are used. In previous emails, I said things like 'system-provided local time description and/or APIs' but they seem only to increase confusion, so let me drop that part. This System time zone will obviously have some system-dependent behaviour, share the system's idiosyncrasies etc. but this is *the whole point*: if the programmer wants them, they should be able to get them.

We have two extremes: portability across systems and blending in with the current system; just like there are two extremes in GUI design: the same GUI being used on all platforms is good because users of the software can freely switch between platforms, but having the common look and feel of the platform the software is running on is good because users of the platform feel at home. PHP's time zone functionality currently forces the programmer to be at the portability extreme; my suggestion is to let the programmer choose which extreme to be at.

(The reasoning for 'system-provided local time description and/or APIs' was that it might be easier to implement some functions by converting /etc/localtime to PHP's internal representation and using PHP's existing internal timezone-aware code than by making a new code branch that calls into the system. As for restoring the guessing algorithm, I suggested that merely as an easier alternative to making a whole new time zone that consistently uses system-provided APIs.)

-- 
Oleg

---

## #56922 — Stas Malyshev — 2011-12-14T21:29:58+00:00

URL: https://externals.io/message/56866#56922 · In reply to: #56921

Hi!

> * There will be a new time zone called System. When this time zone is
> active, instead of PHP's internal time zone database and
> timezone-aware code, system-provided local time APIs are used. In

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. 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.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #56923 — Will Fitch — 2011-12-14T21:53:03+00:00

URL: https://externals.io/message/56866#56923 · In reply to: #56922

I believe he's referring to sys/time.h, but this introduces portability issues.  If it were just unix, that would be one thing.  But maintaining this and a Windows alternative, and I have no idea what that is, is not worth it IMO.  




> Hi!
> 
> > […]
> 
> 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. 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.
> -- 
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227

---

## #56924 — Stas Malyshev — 2011-12-14T22:14:54+00:00

URL: https://externals.io/message/56866#56924 · In reply to: #56923

Hi!

> I believe he's referring to sys/time.h, but this introduces
> portability issues.  If it were just unix, that would be one thing.
> But maintaining this and a Windows alternative, and I have no idea
> what that is, is not worth it IMO.

Yes, portability is questionable. Though if we had a good patch that 
allows to do it, I don't think it would be too bad to have it. Even 
Unix-only might be (again, if enough people need it) fine, if we could 
use the data properly in timelib functions.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #56925 — keisial@gmail.com — 2011-12-14T22:28:04+00:00

URL: https://externals.io/message/56866#56925 · In reply to: #56923

> I believe he's referring to sys/time.h, but this introduces portability issues.  If it were just unix, that would be one thing.  But maintaining this and a Windows alternative, and I have no idea what that is, is not worth it IMO.  
<time.h> is present in *nix, Windows, and probably everywhere php runs.
As it provides mktime/gmtime/localtime, it should be possible to
portably deal with timezones.
At least when it's not multithreaded.
And if the host doesn't contain timezone data (embedded systems,
perhaps), that "System" zone
could simply default to UTC.

---

## #56926 — Stas Malyshev — 2011-12-14T22:44:55+00:00

URL: https://externals.io/message/56866#56926 · In reply to: #56925

Hi!

> 
> > […]
> <time.h>  is present in *nix, Windows, and probably everywhere php
> runs. As it provides mktime/gmtime/localtime, it should be possible
> to portably deal with timezones.

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.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #56927 — Will Fitch — 2011-12-14T22:57:54+00:00

URL: https://externals.io/message/56866#56927 · In reply to: #56926

If enough interest is in this, I'll write a patch with the expectation
for unix based systems initially. I'll have to research the windows
support and reliability.

Who would care to have this (I personally will still be relying on ini)?

Sent from my iPhone



> Hi!
>
> > […]
>
> 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.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227

---

## #56928 — Oleg Oshmyan — 2011-12-14T23:02:32+00:00

URL: https://externals.io/message/56866#56928 · In reply to: #56922

> 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

---

## #56929 — Oleg Oshmyan — 2011-12-14T23:10:41+00:00

URL: https://externals.io/message/56866#56929 · In reply to: #56925

> <time.h> is present in *nix, Windows, and probably everywhere php runs.
> As it provides mktime/gmtime/localtime, it should be possible to
> portably deal with timezones.
> At least when it's not multithreaded.

PHP internally already has php_localtime_r and php_gmtime_r in
main/php_reentrancy.h, implemented in main/reentrancy.c, and they are
already used in various places in the code, including the guessing
algorithm that is being removed in PHP 5.4. So at the very least
thread-safety (and in fact portability too) should not become worse than
it is now.

> And if the host doesn't contain timezone data (embedded systems,
> perhaps), that "System" zone could simply default to UTC.

Sounds good.

-- 
Oleg

---

## #56930 — keisial@gmail.com — 2011-12-14T23:29:42+00:00

URL: https://externals.io/message/56866#56930 · In reply to: #56929

> PHP internally already has php_localtime_r and php_gmtime_r in
> main/php_reentrancy.h, implemented in main/reentrancy.c, and they are
> already used in various places in the code, including the guessing
> algorithm that is being removed in PHP 5.4. So at the very least
> thread-safety (and in fact portability too) should not become worse than
> it is now.
Oh, nice. I thought thet would be doing its own argument passing, based
on timelib, but turns out they do retrive the value from the system
{local,gm}time, even on those without a _r version.

---

## #56931 — Oleg Oshmyan — 2011-12-14T23:41:49+00:00

URL: https://externals.io/message/56866#56931 · In reply to: #56928

> 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)

Actually it might even be fine. The relevant MSDN Library pages are
worded confusingly; I will perform some tests and report back. If
localtime and mktime indeed work well on Windows, I would in fact prefer
them to be used, not just because that will mean less/no platform-
dependent code but also because they honour the TZ environment variable
like POSIX-compliant implementations do.

It is worth mentioning that VC9 has 64-bit and 32-bit versions of time_t,
localtime and mktime while VC6 only has a 32-bit version. Unfortunately,
none of these versions work with times before 1970.

-- 
Oleg

---

## #56932 — Lester Caine — 2011-12-15T07:40:15+00:00

URL: https://externals.io/message/56866#56932 · In reply to: #56931

Oleg Oshmyan wrote:
> It is worth mentioning that VC9 has 64-bit and 32-bit versions of time_t,
> localtime and mktime while VC6 only has a 32-bit version. Unfortunately,
> none of these versions work with times before 1970.

Actually that is probably another discussion, but is the php date function still 
limited to 13 Dec 1901? Personally I still use the ADOdb date functions 
http://phplens.com/phpeverywhere/adodb_date_library which goes back to 100AD, 
and before that if you manage the 2 year date problem. For genealogical data 
it's also necessary to manage the calendar used which does add to the fun ...

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

---

## #56933 — Pierre Joye — 2011-12-15T10:17:25+00:00

URL: https://externals.io/message/56866#56933 · In reply to: #56924

> Hi!
>
>
> > […]
>
>
> Yes, portability is questionable. Though if we had a good patch that allows
> to do it, I don't think it would be too bad to have it. Even Unix-only might
> be (again, if enough people need it) fine, if we could use the data properly
> in timelib functions.

By portability it is not (only) about APIs, APIs wrapping is easy
these days, even on Windows.

But the actual problem is to get a consistent and constantly updated
set of data, reliable data. Data that applications can use blindly on
any platforms without having to worry about bad information, as long
as they use the latest PHP or timezone release (via PECL for example).

And that, as stated earlier, is why we should not provide any
alternative as any other solutions failed so far. It is also even less
important as Oleg's target is the developer environment. If a
developer cannot set his TZ correctly in a php.ini or in his
application on his development box, then something is wrong there, but
not in php :)

For production server, I would never ever suggest to use the system's
TZ, no matter the OS/distros/etc..

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

---

Next page: https://externals.io/message/56866.md?page=2