Timestamp stealing 60 minutes

mrhatch

Good morning everybody,

right now I'm developing a modification for a WoltLab Burning Board for a friend of mine, who thought it might be a good idea to enable the administrators of this forum to write announcements in advance, which are shown on a predefined day in the future.

So far, so good. In order to give you a clue what I did, I give you the piece of code in question in hope someone is able to help me, beacause I must have made a mistage somewhere.

if(checkpermissions("can_time_newthread")==1 && $_POST['r_timercheck']=="0"){
     $day=intval($_POST['day']);
     $month=intval($_POST['month']);
     $year=intval($_POST['year']);
     $hour=intval($_POST['hour']);
     $time=mktime(0,0,0,$month,$day,$year);
     $time+=$hour;
     $threadtimer=1;
   }
   else{
    $time=time();
    $threadtimer=0;
   }

What I did is, I give the administrator some simple dropdown-boxes at the end of the inputform, where he or she is able to define the date and time at which the new thread will first appear in the list of threads. The above code just evaluates formdata and creates a unix-timestamp to be inserted as starttime of the thread.

When I write something in advance of let's say a fortknight everything's working fine, but if I dare to set the date and time to a month from now on, the timestamp lacks a total of exactly 3600 seconds, so the output of my given date (2004-03-29 9 pm comes forth as 2004-03-29 8 pm).

I have no idea where the missing hour could've been lost on it's way into the database.

LordShryku

This looks shady....
$time=mktime(0,0,0,$month,$day,$year);
$time+=$hour;
If they are inputting the hour they want it shown, say 9:00 AM, they would put in 9, right? Then you are essentially adding 9 seconds to the timestamp created from the date? You know, that first zero in mktime is for the hour...

mrhatch

Oh no, I have done it differently.

For time, I created a dropdownbox, too.

$hour=0;
 for($i=1;$i<=48;$i++){
 	 $hour_options .= makeoption($hour,date("H:i",mktime(0,0,$hour)),$_POST['hour'],1);
 	 $hour+=1800;
 }

So, the dropdown is filled like that:

<select name="hour">
<option value="0">00:00</option>
<option value="1800">00:30</option>
<option value="3600">01:00</option>
...
</select>

So, I don't add 9 seconds, but for example 3600 seconds when the new thread should be published at 1 am.

When I correctly understand what you've just said, it is incorrect to just add the e.g. 3600 seconds to the already existing timestamp?

LordShryku

Well, I'm not sure. It just seems un-needed, since mktime also has hour, minute, and second that you can put in there. My bet would be that if you had the minute and second normal, and just plugged it in the mktime statement, you wouldn't have this problem.

mrhatch

So, your opinion is, I should split the dropdownbox and add the two values to the mktime-function?

I just thought, it might be for the user's convenience - and for the looks of the form of couse - to have just one...

LordShryku

Well, for the sake of convenience, you can leave it in one field. Here's what I'd suggest...

<select name="hour">
<option value="0:0">00:00</option>
<option value="0:30">00:30</option>
<option value="1:0">01:00</option> 
<option value="1:30">01:30</option> 
.......
</select>

Basicly the same thing you're already doing, only using a real hour/minute value.
Then just explode them on the next page

$day   = intval($_POST['day']);
$month = intval($_POST['month']);
$year  = intval($_POST['year']);

$split = explode(":",$_POST['hour']);
$hour  = $split[0];
$min   = $split[1];

$time = mktime($hour,$min,0,$month,$day,$year);

Weedpacket

Works fine for a month or so and then goes off by an hour? I can make a guess what that is: it's Daylight Saving coming into effect in your server's timezone.

mrhatch

Yes, that exactly is the "problem" 😉