Why does PHP consider the system's timezone unreliable, and is date_default_timezone_set() required?

[Martin Tournoij]

Message: date() [function.date]: It is not safe to rely on the system's timezone
settings. You are required to use the date.timezone setting or the
date_default_timezone_set() function.

I know *what* this error means, I don't quite understand why PHP considers the
system's timezone unreliable?
All other programming languages I've used just use the systems timezone without
problems, and most applications (servers applications, desktop apps) just use
the system setting.

For example, in C:

#include <time.h>
#include <stdio.h>

int main() {
char out[255];
time_t now = time(0);
struct tm *ltime = localtime(&now);

tzset();
strftime(out, sizeof(out), "%z, %Z", ltime);
printf("%s\n", out);
}

Gives me: +0100, CET, which is the expected output.

Is this somehow unreliable? This is all POSIX stuff, so I would expect it to
work well on at least all POSIX sysyems, or am I missing something?


PS. Please CC me, as I am not subscribed to this list!

Thanks,
Martin

[Stuart Dallas]

Post by Martin Tournoij
Is this somehow unreliable? This is all POSIX stuff, so I would expect it to
work well on at least all POSIX sysyems, or am I missing something?

It doesn’t mean unreliable in the technical sense, just that it’s very common for the timezone of a server to be different from the timezone you want, so it forces you to make a choice. This issue extends beyond shared hosting to dedicated servers where the person who set it up hasn’t changed the timezone from the default. PHP is simply reminding you to check that the timezone is what you want it to be rather than being surprised when it appears that the time is wrong.

There was much discussion about this on the internals mailing list when the notice was introduced, so check those archives if you want more information.

-Stuart

[Tim Streater]

Post by Martin Tournoij
Is this somehow unreliable? This is all POSIX stuff, so I would expect it to
work well on at least all POSIX sysyems, or am I missing something?

It doesn’t mean unreliable in the technical sense, just that it’s very
common for the timezone of a server to be different from the timezone you
want, so it forces you to make a choice. This issue extends beyond shared
hosting to dedicated servers where the person who set it up hasn’t changed
the timezone from the default. PHP is simply reminding you to check that the
timezone is what you want it to be rather than being surprised when it appears
that the time is wrong.

That may be a reasonable thing to do if your PHP is executing on a server. In my case it's on a user's machine and obtaining what the system thinks is the timezone value, just so I can tell PHP, has proved to be a pain in the bum. At least under unix (and so OS X) it seems I can look at what:

/etc/localtime

(which is a link) equates to. I couldn't find any reliable way at all to do it under Windows.

People shouldn't assume that all execution of PHP takes place on a server, because it doesn't.

[Stuart Dallas]

Post by Tim Streater

Post by Stuart Dallas

Post by Martin Tournoij
Is this somehow unreliable? This is all POSIX stuff, so I would expect it to
work well on at least all POSIX sysyems, or am I missing something?

It doesn’t mean unreliable in the technical sense, just that it’s very
common for the timezone of a server to be different from the timezone you
want, so it forces you to make a choice. This issue extends beyond shared
hosting to dedicated servers where the person who set it up hasn’t changed
the timezone from the default. PHP is simply reminding you to check that the
timezone is what you want it to be rather than being surprised when it appears
that the time is wrong.

/etc/localtime
(which is a link) equates to. I couldn't find any reliable way at all to do it under Windows.
People shouldn't assume that all execution of PHP takes place on a server, because it doesn’t.

I’m not going to get in to the arguments for and against because it was done to death at the time, but you must understand that your use case is incredibly rare for PHP. To get around your issue you can use the following to use the system timezone without getting the notice:

date_default_timezone_set(@date_default_timezone_get());

-Stuart

[Tim Streater]

Post by Tim Streater
People shouldn't assume that all execution of PHP takes place on a server,
because it doesn’t.

I’m not going to get in to the arguments for and against because it was done
to death at the time, but you must understand that your use case is incredibly
rare for PHP.

You sure? I would have thought that as PHP is so easy to use, lots of people might write all their local command line scripts in it. I do - it would never occur to me not to.

To get around your issue you can use the following to use the

This just gives me UTC, not the timezone the user has set.

[Andy McKenzie]

Post by Tim Streater

Post by Tim Streater
People shouldn't assume that all execution of PHP takes place on a

server,

Post by Tim Streater
because it doesn't.

I'm not going to get in to the arguments for and against because it was

done

to death at the time, but you must understand that your use case is

incredibly

rare for PHP.

You sure? I would have thought that as PHP is so easy to use, lots of
people might write all their local command line scripts in it. I do - it
would never occur to me not to.

Yeah, it's pretty rare. Most people who find a need to write command line
scripts in Windows are programmers, who are probably going to use Python or
VB, or they're system administrators, and they're going to use something
like VB. For Linux and Mac OS, you can do most things pretty simply with
shell scripting, and not have the hassle of running it through an
interpreter. And I suspect that most people who are writing significant
scripts for command line in Linux or OSX are going to use Python these days
if shell scripting isn't powerful enough: as much as I like PHP, Python
has some benefits there.

[Stuart Dallas]

Post by Tim Streater

Post by Stuart Dallas

Post by Tim Streater
People shouldn't assume that all execution of PHP takes place on a server,
because it doesn’t.

I’m not going to get in to the arguments for and against because it was done
to death at the time, but you must understand that your use case is incredibly
rare for PHP.

You sure? I would have thought that as PHP is so easy to use, lots of people might write all their local command line scripts in it. I do - it would never occur to me not to.

I write a lot of CLI scripts using PHP, but they’re all executed server-side. I have very few local scripts because there’s little that I need to do enough to warrant a script that can’t be done by piping a few existing commands together.

Post by Tim Streater

Post by Stuart Dallas
To get around your issue you can use the following to use the

This just gives me UTC, not the timezone the user has set.

Sorry, I didn’t have time to test it. I don’t know what else to suggest. If these are local CLI scripts for your own usage, why not just hardcode timezone? If the timezone is actually important for your scripts you can instead set the timezone in your local php.ini which will make it correct unless you ever travel and need it to be local, at which point I’d wonder what you’re doing that needs such a reactive timezone value.

-Stuart

[Per Jessen]

Post by Tim Streater

Post by Stuart Dallas

Post by Tim Streater
People shouldn't assume that all execution of PHP takes place on a
server, because it doesn’t.

I’m not going to get in to the arguments for and against because it
was done to death at the time, but you must understand that your use
case is incredibly rare for PHP.

You sure? I would have thought that as PHP is so easy to use, lots of
people might write all their local command line scripts in it. I do -
it would never occur to me not to.

We do too, lots of them. It's much easier to keep scripts and websites
in the same language.

[Tim Streater]

Post by Tim Streater
This just gives me UTC, not the timezone the user has set.

Sorry, I didn’t have time to test it. I don’t know what else to suggest.
If these are local CLI scripts for your own usage, why not just hardcode
timezone? If the timezone is actually important for your scripts you can
instead set the timezone in your local php.ini which will make it correct
unless you ever travel and need it to be local, at which point I’d wonder
what you’re doing that needs such a reactive timezone value.

The app is an email client. So it runs wherever the user is (all parts of the app run on the user machine, including apache and the PHP scripts). So I can't hardcode it. As I described earlier, for OS X and unix I have a way to get it; it's Windows that's the problem. When I get a round tuit I'll add a user setting so they can enter it themselves.