Hi,

can you please put all this information in the bugreport, so that we can 
track thie proceedings of this problem? I'll assign it to myself that so 
that I won't forget about it either :)

regards,
Derick

On Mon, 18 Aug 2003, Luke Ehresman wrote:

> Hi,
> 
> A co-worker and I have been working on some intensive timestamp/timezone
> manipulation code for the past week or so, and ran across what we believed
> to be a bug in the way PHP handled gmmktime().  Browsing through the code,
> sure enough I found the source of the problem.  I fixed it, and have
> attached a patch.
> 
> As I was searching around, I discovered that this has been an open bug
> since 4.0.6 (2 years!).  I believe that this patch should fix most of the
> issues related to the following problem:
>     http://bugs.php.net/bug.php?id=14391
> 
> 
> The Problem:
> ============
> The function gmmktime() is supposed to take a date in GMT as a paramter
> and return a timestamp in GMT.  No manipulation of the time should occur.
> The only circumstance in which manipulation of the time should happen is
> if the seventh parameter (is_dst) is set to 1.  This is the expected
> behavior.  However, in reality I noticed that when I didn't specify a
> seventh parameter, it was applying a daylight savings time offset when I
> tried to get the epoch.  See the example code.
> 
> <?php
> 
>     // Get a timestamp for the epoch (jan 1, 1970)
>     echo "<pre>";
>     echo gmmktime(0,0,0,1,1,1970,1)."\n";
>     echo gmmktime(0,0,0,1,1,1970,0)."\n";
>     echo gmmktime(0,0,0,1,1,1970)."\n";
> 
>     // Now get timestamp for June 1
>     echo "\n";
>     echo gmmktime(0,0,0,6,1,1970,1)."\n";
>     echo gmmktime(0,0,0,6,1,1970,0)."\n";
>     echo gmmktime(0,0,0,6,1,1970)."\n";
> 
> ?>
> 
> I expected the first set of outputs to look like this:
> 
>     -3600
>     0
>     0
> 
> Which it does, so this is fine.  However, The second block of outputs is
> in June which if I had been using simply mktime(), I would have expected a
> DST offset (note: DST = daylight savings time) to be applied by default
> (on the 3rd command).  However, since I'm using gmmktime() by default no
> DST offset should be applied.  The odd behavior manifests itself in the
> second block of output:
> 
>     13046400
>     13050000
>     13046400
> 
> This is pretty meaningless until you realize what is actually going on.
> The last output, which is generated by a gmmktime() that has no 7th
> parameter, is applying an offset for daylight savings time.
> 
> The Solution
> ============
> I had a moment of panic and was sincerely hoping that GMT did not actually
> use daylight savings time, so I did some research and found that while the
> timezone that contains Greenwich actually does use daylight savings time,
> the GMT standard time reference does not.  So right there I knew something
> was wrong on the PHP side.  I loaded up the source of PHP (like a good
> open source enthusiast), and sure enough, I discovered the source of the
> problem (no pun intended).
> 
> PHP is using the C function php_mktime() for both mktime() and gmmktime().
> There is a flag as a parameter called "gm" which is 1 or 0 depending on
> whether it was called from mktime() or gmmktime().  The problem is that
> there is no check before applying the server's daylight savings
> information to the timestamp.
> 
> As a fix for this, I changed the behavior so that by default if there is
> no 7th parameter for gmmktime, it will not apply any DST offset.  This
> differs from mktime which by default will appy the server's DST offset.
> 
> I have attached patches for both PHP php-5.0.0b1 and php-4.3.2.  I would
> imagine the same code would work on most recent versions of PHP as it
> doesn't seem that this function has had much recent development.  The
> patch can be applied by using the following:
> 
>     $ cd /usr/local/php-4.3.2
>     $ patch -p2 < ~/gmmktime-php_4.3.2.patch
> 
> Feel free to contact me if you have any questions.
> 
> Luke
> 

-- 
"Interpreting what the GPL actually means is a job best left to those
                    that read the future by examining animal entrails."
-------------------------------------------------------------------------
 Derick Rethans                                 http://derickrethans.nl/ 
 International PHP Magazine                          http://php-mag.net/
-------------------------------------------------------------------------


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to