Does UTC take DST into account?

[Daz]

Hi everyone. I know this question sounds stupid, but it's been
plaguing me, and as I can't seem to find the answer, and can't afford
to wait until the end of March for DST to kick into effect, I thought
I should ask here.

On my server, when I do:

echo date("0", mktime());

I get -0500. This suggests to me that the server is 5 hours behind GMT/
UTC time.

When I do:

echo gmdate("0", mktime());

I get +0000 , which is correct. However, the time I get is 1 hour 1
minute and 52 seconds ahead of what the actual GMT time is.

Does this mean that the locale is wrong, or would I simply subtract
and hour from the supposed GMT and get on with it?

The question that's plaguing me, is will the time leap forward on the
last Sunday of March, and would it be affected by whether or not the
country that the server is in conforms to DST?

I need to utilise a constant time (UTC), so I can tweak my script, and
never have to worry about different timezones and DST, but I am not
sure if I am doing it the right way.

I would appreciate it if someone could point out where I might be
going wrong (if anywhere), or whether it sounds like the server
locales are set incorrectly from what I have tried to explain.

Many thanks in advance.

Daz.

[Daz]

On Feb 11, 3:15 am, ljb <[e-mail]:

[e-mail] wrote:

Hi everyone. I know this question sounds stupid, but it's been
plaguing me, and as I can't seem to find the answer, and can't afford
to wait until the end of March for DST to kick into effect, I thought
I should ask here.

If you are in US or Canada, and your -0800 offset implies that, that would
be 2nd Sunday in March, not end of March. Just so you know. (And spelling
'utilise' implies Canada, I guess. Someplace like Vancouver?)

It's -0500, not -0800 :)

>

On my server, when I do:

echo date("0", mktime());

I get -0500. This suggests to me that the server is 5 hours behind GMT/
UTC time.

Assuming the server's timezone is set correctly, it is perhaps in east
coast US, eastern Canada, or even western South America. (FYI that's "O"
letter Oh, not "0" zero.) You could print out date('T') to see the timezone
name, or even better with PHP>=5.1 date('e') to see the descriptive name.

When I do:

echo gmdate("0", mktime());

I get +0000 , which is correct. However, the time I get is 1 hour 1
minute and 52 seconds ahead of what the actual GMT time is.

That's odd. How did you get that time?
If it was just 1 min 52 seconds, I would say the server time is
unsynchronized (assuming your time is accurate). But I don't understand
the hour. If that's really the server's GMT time, that would be bad.

I did echo gmdate("M d Y H:i:s", mktime());

And the time is an hour ahead of my PC clock, which is in the UK and
synchronised. Just in case, I checked out http://
wwp.greenwichmeantime.com/ which displays the correct GMT, which
displays the same time as my PC clock (to the second).

>

Does this mean that the locale is wrong, or would I simply subtract
and hour from the supposed GMT and get on with it?

Locale has nothing to do with it. The server's timezone setting is
used to produce local time. UTC (GMT) is UTC no matter what.
I would probably ask the server/hosting company what's up there.

I did exactly that. I asked them to look into it, they said they
would, and never got back to me. Heh. They are usually pretty good, so
I will give them a kick in the butt.

>

The question that's plaguing me, is will the time leap forward on the
last Sunday of March, and would it be affected by whether or not the
country that the server is in conforms to DST?

UTC doesn't change. Local time is subject to the timezone setting; that
would default to the server's timezone or your scripts can set it.
If the selected timezone includes a DST change, local time changes.
In most of US and Canada, local time jumps 1 hour on March 11, 2007.

Oh, I see. Excellent. It makes complete sense now.

>

I need to utilise a constant time (UTC), so I can tweak my script, and
never have to worry about different timezones and DST, but I am not
sure if I am doing it the right way.

I would appreciate it if someone could point out where I might be
going wrong (if anywhere), or whether it sounds like the server
locales are set incorrectly from what I have tried to explain.

What I recommend you need to be sure this all works:
1. Your server O/S needs up-to-date timezone data (if Linux or Unix),
or Microsoft patches (if Windows). Less important for PHP>=5.1
which has its own timezone database, I think.

Ironically enough, I switched over to PHP 5 yeasterday. The settings
take about 15 minutes to propagate, and I never went back and checked
it then. I just checked it now, and my Control Panel says I am running
PHP 5.1, but running:
php -version
at the command line, reveals I am still running php 4.4.2. I'll get
them to look into that.

I just logged in, and when I do 'date' at the CL, I get: Sun Feb 11
08:41:14 EST 2007

For my PC (Linux), I get: Sun Feb 11 12:38:17 UTC 2007

That means the server time is actually -0400, not -0500 like PHP says.
This is so confusing...

Also, both dates were taken within 0.5 seconds of oneanother.

2. Your server's time should be synchronized with NTP. Should go without
saying, but sometimes ignored, sadly.

Yeah, I think I am going to speak to my host about that.

3. Use an up-to-date PHP version like 5.2.0.

Hmmm. I think we only have 4, 5 or 5.1 available for grabs at the
moment. Can you confirm it's safe, and backwards compatible. I heard
there were some problems in the past, but I don't know if they were
rumours, or if the problems have been fixed or not. Either way, I
didn't want to take the chance with my Web site.

4. Your timezone should be set to match your (or your users) timezone - not
necessarily the server's timezone. If you control the server's php.ini,
set it there with "date.timezone". If not, then set it in your scripts with
date_default_timezone_set(). (These are for PHP 5.1 and up, I think.)

You are right. Thank you very much for your input. I am pretty certain
now that there is a problem with the server. :)

Daz.