Daylight Savings Time not supported? Daylight Savings Time not supported?
 

News:

cpg1.5.48 Security release - upgrade mandatory!
The Coppermine development team is releasing a security update for Coppermine in order to counter a recently discovered vulnerability. It is important that all users who run version cpg1.5.46 or older update to this latest version as soon as possible.
[more]

Main Menu

Daylight Savings Time not supported?

Started by Pastinakel, August 12, 2006, 05:22:58 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Pastinakel

Living in a CET timezone country I just noticed that CopperMine gives me the wrong time.

The difference between GMT and CET is +1 in winter and +2 in summer. I have set the time difference to +1 in CopperMine.

Examining the code a found the function that should correct the timestamp for the current timezone. But this function does not calculate the effect of Daylight Savings Time (DST).

I think the solution is very simple and requires a minimum of work, using the date("I") function:

Quote
string date ( string format [, int timestamp] )
[...]
I (capital i)   Whether or not the date is in daylights savings time   1 if Daylight Savings Time, 0 otherwise.
from http://nl2.php.net/manual/en/function.date.php

The mod to the function localised_timestamp in include/functions.inc.php:

function localised_timestamp($timestamp = -1)
{
        global $CONFIG;

        if ($timestamp == -1) {
        $timestamp = time();
    }

    $diff_to_GMT = date("O") / 100;

// Start Mod: follow DST
//    $timestamp += ($CONFIG['time_offset'] - $diff_to_GMT) * 3600;
    $timestamp += ($CONFIG['time_offset'] + date("I") - $diff_to_GMT) * 3600;
// End Mod: follow DST

        return $timestamp;
}


Version: subversion stable aug 10, 2006

Pastinakel

Blast, the problem is more complicated than I expected.

The function localised_timestamp () works with the value of date("O") and that value is dependent on the timezone the webserver is configured for. The function localised_timestamp tries to correct for the timezone the server is in but this timezone determines if the server time is affected by DST or not: GMT is not affected by DST, all other timezones are (as far as I know, at least CEST is).

So on my server (that is in the same TZ as I am) no correction for time is neede because the date functions do all the adjustments for me.

The adjustment code from the CopperMine script:


$diff_to_GMT = date("O") / 100;
$timestamp += ($CONFIG['time_offset'] - $diff_to_GMT) * 3600;


removes the correction PHP does in the funtion strftime(). That function is used in Coppermine's localised_date () function.

Let me put in in steps, based on my system where the TZ is CEST (at the moment GMT+2 / DST is on). The local time is  23:47:47.

A. there is the $timestamp (GMT timestamp, seconds since UNIX epoch) -> 1155419267
B. $timestamp = localised_timestamp($timestamp);
C. $timestamp += ($CONFIG['time_offset'] - $diff_to_GMT) * 3600;
    $timestamp += ($CONFIG['time_offset'] - (date("O") / 100)) * 3600;
    $timestamp += (1 - 2) * 3600; -> 1155415667
By now we have a GMT timestamp that is adjusted for the difference to GMT.
D. return strftime("%T", $timestamp); -> 22:47:47

Voila: 1 hour different.   :'(
That is because strftime is correcting again for the timezone.

At this moment I do not know what should be the correct code but maybe I made a mistake somewhere. I'm very interested in what other people think about this. When I started with PHP the time and date functions always made me dizzy en they still do sometimes...  :-\  ;)

I think the right way to do it would be as simple as:


$diff_to_GMT = date("O") / 100;
$timestamp += ($CONFIG['time_offset']) * 3600;

Joachim Müller

Daylight saving time starts and ends on different days, depending on which country you're in. That's why there can be no automatism built into coppermine. Time zone differences are one of the most complicated issues existing in PHP / webserver technology.

Nibbler

The problem here is that changing the timezone changes the time displayed for things that have already happened. If you post a comment at 3pm and then set the timezone forward an hour the comment appears to have been written at 4pm. Fixing this is not a simple task, and imo the work involved and added code complexity are not worth it for a relatively trivial feature.

Pastinakel

Quote from: Nibbler on August 16, 2006, 05:04:46 PM
The problem here is that changing the timezone changes the time displayed for things that have already happened. If you post a comment at 3pm and then set the timezone forward an hour the comment appears to have been written at 4pm. Fixing this is not a simple task, and imo the work involved and added code complexity are not worth it for a relatively trivial feature.
Well, I suppose that it's exactly what is supposed to happen if you change timezones: everything has happened on a different time compared to the timezone you were previously in.

I might be wrong but the whole problem can be fixed if you strictly adhere to the system where all times are kept internally in a GMT timestamp and all times are presented to the user converted to the local timezone the user is in.
As far as I know CP stores all timestamps in GMT so it should not be too hard to fix this trivial feature.

I'll come back to this, there are some ideas boiling in the back of my head...