strftime geeft uur teveel op
code:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?php
// In mijn script komen de waarden uit een array, daarom geef ik hieronder even twee variablen weer voor het goede begrip:
$aGetUren[0]['uren_begin'] = '8:00';
$aGetUren[0]['uren_eind'] = '10:00';
// Begin eigenlijke script
$begin = explode(':',$aGetUren[0]['uren_begin']);
$eind = explode(':',$aGetUren[0]['uren_eind']);
$begin = mktime($begin[0],$begin[1],0,0,0,0);
$eind = mktime($eind[0],$eind[1],0,0,0,0);
$totaal = $eind - $begin;
echo strftime('%H:%M',$totaal);
// Geeft weer: 03:00 moet zijn 02:00
?>
// In mijn script komen de waarden uit een array, daarom geef ik hieronder even twee variablen weer voor het goede begrip:
$aGetUren[0]['uren_begin'] = '8:00';
$aGetUren[0]['uren_eind'] = '10:00';
// Begin eigenlijke script
$begin = explode(':',$aGetUren[0]['uren_begin']);
$eind = explode(':',$aGetUren[0]['uren_eind']);
$begin = mktime($begin[0],$begin[1],0,0,0,0);
$eind = mktime($eind[0],$eind[1],0,0,0,0);
$totaal = $eind - $begin;
echo strftime('%H:%M',$totaal);
// Geeft weer: 03:00 moet zijn 02:00
?>
Als ik $totaal (7200) zelf met me rekenmachine deel door 3600 kom ik op 2 uur. PHP komt op 3 uur.
Iemand enig idee wat er fout gaat?
PS: ik heb al gekeken of ik in de mktime niet perongelijk een octaal getal gebruik als uur. Daarom heb ik voor i.p.v. $begin[0]: intval($begin[0]) gebruikt, zonder resultaat.
je servertijd zal wel fout zijn?
Edit: net getest op een totaal andere computer - ook XAMPP configuratie, maar hetzelfde aantal uren 03:00.
Gewijzigd op 01/01/1970 01:00:00 door kvdd
Problemen met deze aanpak krijg je bijvoorbeeld als het verschil groter is dan 24 uur, strftime() zal dan namelijk gewoon weer bij 00:00 verder gaan omdat dat als de volgende dag gezien wordt.
Als je met verschillen tussen timemstamps aan de gang gaat in PHP, zul je toch echt zelf de uren en minuten moeten bepalen door de betreffende delingen uit te voeren...
kvdd schreef op 20.05.2008 14:50:
Geeft weer: 03:00 moet zijn 02:00
Geeft bij mij 01:00
Daar kunnen afhankelijk van je locale settings verschillende waarden uit komen. Kortom, strftime() is niet geschikt om in deze toepassing te gebruiken.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<?php
ini_set('display_errors', 1); // 0 = uit, 1 = aan
error_reporting(E_ALL);
$aGetUren[0]['uren_begin'] = '8:00';
$aGetUren[0]['uren_eind'] = '10:00';
// Begin eigenlijke script
$begin = explode(':',$aGetUren[0]['uren_begin']);
$eind = explode(':',$aGetUren[0]['uren_eind']);
$begin = mktime($begin[0],$begin[1],0,0,0,0);
$eind = mktime($eind[0],$eind[1],0,0,0,0);
$totaal = $eind - $begin;
$timediff = explode(':', strftime('%H:%M', 0));
echo strftime('%H:%M',$totaal + $timediff[0] * 3600);
?>
ini_set('display_errors', 1); // 0 = uit, 1 = aan
error_reporting(E_ALL);
$aGetUren[0]['uren_begin'] = '8:00';
$aGetUren[0]['uren_eind'] = '10:00';
// Begin eigenlijke script
$begin = explode(':',$aGetUren[0]['uren_begin']);
$eind = explode(':',$aGetUren[0]['uren_eind']);
$begin = mktime($begin[0],$begin[1],0,0,0,0);
$eind = mktime($eind[0],$eind[1],0,0,0,0);
$totaal = $eind - $begin;
$timediff = explode(':', strftime('%H:%M', 0));
echo strftime('%H:%M',$totaal + $timediff[0] * 3600);
?>
Blanche schreef op 20.05.2008 15:10:
En daar komt bij mij 01:00 uit. Idd klopt er weinig van.
Maar op welke manier rekenen jullie dan met tijd?
Zo?
ps. Het rekenen met data en tijden laat ik bijna altijd aan de database over. In PHP is dat altijd een vervelende klus terwijl het voor de database een fluitje van een cent is...
Gewijzigd op 01/01/1970 01:00:00 door Joren de Wit
Blanche schreef op 20.05.2008 15:23:
Het rekenen met data en tijden laat ik bijna altijd aan de database over. In PHP is dat altijd een vervelende klus terwijl het voor de database een fluitje van een cent is...
Die array van mij is data, die ik heel veel gebruik in mijn script. Wat ik kan doen, is natuurlijk de uren nogmaals uit de database halen, maar dan uitgerekend en wel.
Dat zou nog minder vergen van de server ook, imo.
Edit: @SanThe bij mij komt er ook 4 uit :)
Gewijzigd op 01/01/1970 01:00:00 door kvdd
Blanche schreef op 20.05.2008 15:23:
@SanThe: dat geeft bij mij 04:00 ;-)
Vreemd, maar het was te proberen. Ik heb ooit iets gemaakt dat correct werkt. Ik kan het alleen nergens meer vinden en ik weet ook niet meer precies hoe ik het had gedaan. :-(
Met de query die je op de database uitvoert, bereken je alle benodigde gegevens en zet je alles in het juiste formaat. PHP gebruik je dan enkel om het resultaat uit de database weer te geven, meer niet...
ps. Toch nog een klein voorbeeldje van het rekenen met data en tijden in PHP:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<?php
$sBegin = '2008-05-20 08:29:33';
$sEind = '2008-05-21 08:40:19';
$iBegin = strtotime($sBegin);
$iEind = strtotime($sEind);
$iVerschil = $iEind - $iBegin;
$iUren = $iVerschil / 3600;
$iVerschil %= 3600;
$iMinuten = $iVerschil / 60;
$iVerschil %= 60;
$iSeconden = $iVerschil;
echo sprintf('%02d:%02d:%02d', $iUren, $iMinuten, $iSeconden);
?>
$sBegin = '2008-05-20 08:29:33';
$sEind = '2008-05-21 08:40:19';
$iBegin = strtotime($sBegin);
$iEind = strtotime($sEind);
$iVerschil = $iEind - $iBegin;
$iUren = $iVerschil / 3600;
$iVerschil %= 3600;
$iMinuten = $iVerschil / 60;
$iVerschil %= 60;
$iSeconden = $iVerschil;
echo sprintf('%02d:%02d:%02d', $iUren, $iMinuten, $iSeconden);
?>
En dan in SQL:
Zoals je ziet is dat vele malen korter en sneller!
@Blance, dankje, dan lijkt SQL me beter ;)
Nog iets, de uren/tijden die ik in de database heb staan, staan elk in een tabel van de betreffende maand.
Soms komt het voor dat ik voor één en dezelfde week, twee maanden heb, omdat de volgende maand halverwege de week begint.
Dus me vraag is, is het mogelijk dat SQL ook rekend met verschillende tijden:
en met verschillende tabellen:
Misschien is het niet netjes dat ik het vraag zonder het eerst geprobeerd te hebben, maar als ik weet dat het mogelijk is, dan is dat reden voor mij om door te gaan met de (cleanere) SQL oplossing :)
Quote:
Je hebt voor elke maand een aparte tabel? Als dat zo is heb je een hele grote fout gemaakt!de uren/tijden die ik in de database heb staan, staan elk in een tabel van de betreffende maand.
Dat is namelijk een compleet verkeerde opzet van je datamodel en dat gaat je zeker nog problemen opleveren. Hoe wil jij nu bijvoorbeeld gegevens over een heel jaar gaan bepalen? Of hoe gaat je dat doen met begin en eindtijden die in verschillende maanden vallen?
Ga normaliseren en een goed datamodel opzetten. Hiermee verder werken is echt vragen om de grootste problemen...
Maar één ding heb ik niet begrepen, daarom staan uit voorzorg de uren per maand in een tabel, dat is indexeren. Eerst had ik één tabel: uren. Die zou mijns inziens na 1 jaar veel te groot worden, en zou de snelheid van de website dusdanig naar beneden halen.
Ik heb een rekensom gedaan:
Aantal werkdagen * werknemers wordt 230 * 120 = 27.600 rijen. Vandaar dus mijn indeling op die manier. Zelf uitgevonden *kuch* :)
Met begin en eindtijden loopt het goed af, dat heb ik getest. Er wordt namelijk bij het plaatsen, en het ophalen uit de tabel naar de begintijd gekeken, in welke maand die valt.
Op welke manier zou jij het doen? 1 tabel?
Gewijzigd op 01/01/1970 01:00:00 door kvdd
Quote:
Hier hoef je je echt geen zorgen over te maken, 28.000 records is voor een database echt 10x niks. Tabellen kunnen met gemak tientallen miljoenen records bevatten, dus wat dat betreft kun je nog wel een aantal jaartjes doorgaan ;-)Aantal werkdagen * werknemers wordt 230 * 120 = 27.600 rijen.
Ik doe het serieus alleen maar daarom :-) hmm grappig, maar beter nu omgooien, dan als het af is!
Ik heb overigens 16 velden per rij, maakt dat ook niet uit? Mijn gevoel zei toen ik op deze manier mijn tabellen structuur opzette, dat het nogal lastig zoeken is voor me MySQL5 database alstie nu net dat ene uur moet hebben veld 16 en rij 540.000, snap je? <- deze situatie maakt dus nog niet uit qua snelheid voor MySQL als ik het goed begrijp
Wat betreft capaciteit wist ik idd dat het aantal records weet ik hoeveel mag zijn, maar qua snelheid dus niet.
Mooi tabel uren in aanmaak ;-)
Gewijzigd op 01/01/1970 01:00:00 door kvdd
Quote:
Als uit normaliseren gebleken is dat jouw tabel 16 kolommen moet tellen, is dat absoluut geen probleem. Als (een aantal van) deze kolommen echter dezelfde soorten data bevatten, is het weer niet goed. Dat is vaak eenvoudig te zien doordat kolomnamen dan genummerd kunnen worden, bijvoorbeeld 'auto1', 'auto2', etc. Normaliseren is hier wederom het kernwoord.Ik heb overigens 16 velden per rij, maakt dat ook niet uit
Een tabel met heel veel records is geen probleem. Om de snelheid van je queries te waarborgen zul je dan wel indexen aan moeten brengen op de juiste kolommen. Meer daarover lees je in deze tutorial.
Idd uit normalisatie bleek gewoon dat ik er 16 nodig had. Ik heb wel een aantal kolommen die dezelfde soort data, namelijk INT(1) bevatten, stuk of 6. Die hebben als een ja/nee (1 of 0) functie voor bepaalde onderdelen van de uren. (Ik ben geen PHP expert, maar het leek me dat dit bijna geen belasting is voor de database)
Maar ik heb geen totaal van uren (optellingen) etc. erin staan, die ik gewoon kan berekenen uit de data die in de tabel staan. Met andere woorden, ik heb genormaliseerd :)
Je tutorial heb ik een stukje al van gelezen, die ga ik doorspitten als ik weer op me werk ben. Goed werk!