WeBid Bug Tracking

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000002WeBidAuctionspublic2009-03-29 10:492009-06-18 00:47
Reporterrenlok 
Assigned To 
Priority@0@SeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version0.7.3 / 0.7.4 
Target VersionFixed in Version0.8.0 
Summary0000002: Time bug
DescriptionWhen creating an auction the time will be 1 hour ahead of what it should be, but can only be replicated on a few instances.



http://www.webidsupport.com/forums/showthread.php?t=539[/url] [^]
TagsNo tags attached.
import_id2
Thread
Attached Files

- Relationships

-  Notes
(0000083)
dannywiz (viewer)
2009-05-31 12:55
edited on: 1970-01-01 00:00

A time increment also happens whenever you modify the auction before the final confirm. It seems that the time is increased every time the input form is loaded.
(0000087)
Box Lot (reporter)
2009-05-31 17:06
edited on: 1970-01-01 00:00

Links broken Renlok, did you mean http://www.webidsupport.com/forums/project.php?issueid=16?[/url] [^]
(0000094)
renlok (administrator)
2009-06-13 08:14
edited on: 1970-01-01 00:00

according to post at drupal.org this is a bug that occurs with some versions of PHP
http://groups.drupal.org/node/4838[/url] [^]

but it also offers a fix thats i would assume works
http://groups.drupal.org/node/4838#comment-43091[/url] [^]

but anyway we could try it check if it works.
(0000095)
Box Lot (reporter)
2009-06-13 18:17
edited on: 2009-06-13 18:19

Are you planning on integrating the solution into the package?

Think this is effecting the "make changes" bug?
http://www.webidsupport.com/forums/project.php?issueid=16&page=2#note140[/URL] [^]

Happy to test some solutions for you.
(0000096)
renlok (administrator)
2009-06-14 19:03
edited on: 2009-06-14 19:03

well ill add it for next release but it would great if you could test it see if it actually works

could you add
[PHP]function _gmmktime($hr, $min, $sec, $mon, $day, $year, $null = null)
{
    if (gmmktime(0,0,0,6,1,2008, 0) == 1212282000)
    {
        //Seems to be running PHP (like 4.3.11).
        //At least if current local timezone is Europe/Stockholm with DST in effect, skipping the ,0 helps:
        return gmmktime($hr, $min, $sec, $mon, $day, $year); //without is_dst-parameter at the end
    }
    return gmmktime($hr, $min, $sec, $mon, $day, $year, 0);
}[/PHP]
to sellfunctions.inc.php

and in sell.php change all instanses of
[PHP]gmmktime([/PHP]
to
[PHP]_gmmktime([/PHP]

and im hoping that sould fix all the time related issues, if not well have to try out some other things
(0000097)
Box Lot (reporter)
2009-06-15 05:52
edited on: 2009-06-15 06:01

2 instances found in sell.php.

Well it didn't fix the loss of an hour for me when selecting to make changes prior to submitting a new auction.


Plus now I'm back to losing an hour when going straight through with a listing.

Editing an auction will take away another 2 hours. Cumulative effect, subtracting 2 hours for every time you edit the auction.
That was an issue prior to these edits but it was 1 hour.

Let me know anything else to look at and/or future changes.
(0000098)
renlok (administrator)
2009-06-15 11:26
edited on: 1970-01-01 00:00

ok change the function to
[PHP]function _gmmktime($hr, $min, $sec, $mon, $day, $year, $null = NULL)
{
    $gmmktime = gmmktime($hr, $min, $sec, $mon, $day, $year);
    if (date('I', $gmmktime) == 0)
    {
        $testtime = gmmktime(0,0,0,6,1,2008);
        $actualvalue = 1212278400;
    }
    else
    {
        $testtime = gmmktime(0,0,0,1,1,2008);
        $actualvalue = 1199145600;
    }
    //$testtime += 3600;
    if ($testtime == $actualvalue)
    {
        return $gmmktime;
    }
    else
    {
        return $gmmktime - ($testtime - $actualvalue);
    }
}[/PHP]
that seems to work
(0000099)
Box Lot (reporter)
2009-06-15 14:43
edited on: 1970-01-01 00:00

We have a winner!

Just to clarify, since it is not again noted, if you have this issue you need to make both the addition to /includes/sellfuncitons.inc.php noted just above and the previously mentioned replacements to sell.php.

Thanks yet again for the diligence Renlok despite the relatively low occurrence, some might have written it off and moved on.

Hopefully now we've seen the last of the date/time issues!
(0000100)
Box Lot (reporter)
2009-06-16 01:30
edited on: 1970-01-01 00:00

Ok, for those with similar/same issues, I had an old time edit/fix in my sell.php that I just recently added and forgot to remove (it was late even for me!)

So to solve the time issue the first edit for sellfunctions.inc.php is best. Here are the correct edits again:

renlok wrote



could you add
[PHP]function _gmmktime($hr, $min, $sec, $mon, $day, $year, $null = null)
{
    if (gmmktime(0,0,0,6,1,2008, 0) == 1212282000)
    {
        //Seems to be running PHP (like 4.3.11).
        //At least if current local timezone is Europe/Stockholm with DST in effect, skipping the ,0 helps:
        return gmmktime($hr, $min, $sec, $mon, $day, $year); //without is_dst-parameter at the end
    }
    return gmmktime($hr, $min, $sec, $mon, $day, $year, 0);
}[/PHP]to sellfunctions.inc.php

and in sell.php change all instanses of
[PHP]gmmktime([/PHP]to
[PHP]_gmmktime([/PHP]


Thanks to Renlok for continuing to track and fix these time issues that in one form or another have been going on from the start, I believe he's quashed them once and for all!

- Issue History
Date Modified Username Field Change
2015-04-01 13:17 renlok New Issue
2015-04-01 13:17 renlok import_id => 2
2015-04-01 13:17 renlok Date Submitted 2015-04-01 13:17 => 2009-03-29 10:49
2015-04-01 13:17 renlok Last Update 2015-04-01 13:17 => 2009-06-18 00:47


Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker