[PHP] Probleem met date() en timestamps voor 1970

[posttoast]

Ik ben een website aan het bouwen waarop mensen een geboortedatum in kunnen voeren. Omdat ik het zo lullig vind om iedereen boven de 36 hierbij uit te sluiten, zou het leuk zijn als er ook geboortedata van voor 1970 ingevoerd kunnen worden. En dat is een probleem.

Na wat zoekwerk kwam ik erachter dat PHP4 op Windows nogal wat moeite heeft met negatieve timestamps. Hierdoor kan de strtotime() functie niet gebruikt worden. Wat meer speurwerk leverde mij een alternatieve functie op (zie hier) en die werkt goed. Maarrr: ik moet de timestamp ook weer terug kunnen vertalen naar een date-format om op de site te tonen. En ook de date() functie kan onder Windows blijkbaar niet goed overweg met een negatieve timestamp. Deze fijne error krijg ik:

Warning: date() [function.date]: Windows does not support dates prior to midnight (00:00:00), January 1, 1970

Na heel veel zoeken is de enige oplossing die ik heb gevonden PHP5 te installeren. Maar laat dat hier nu net geen optie zijn. Kortom: ik zoek een (handmade?) alternatief voor de date() functie, zodat ik wél geboortedata van voor 1970 kan gebruiken. Iemand tips?

[Zyppora]

Wat ik doe is de dag + maand van de geboortedatum in een timestamp opslaan (onder het jaar 2000 of zo) en dan het geboortejaar als aparte int. Is één extra column in je database, maar scheelt je een hoop ellende.

[posttoast]

Zyppora schreef op woensdag 24 januari 2007 @ 15:59:
Wat ik doe is de dag + maand van de geboortedatum in een timestamp opslaan (onder het jaar 2000 of zo) en dan het geboortejaar als aparte int. Is één extra column in je database, maar scheelt je een hoop ellende.

Kan, maar vind ik niet de meest chique oplossing. Ik vind het een beetje zonde om mijn databasemodel aan te moeten passen aan de tekortkomingen van Windows/PHP.

Maar ik houd hem in mijn achterhoofd

[frickY]

Datums sla je op in een DATE danwel DATETIME veld.. niet als Unix timestamp in een int-veld.

[Zyppora]

Is het ophogen van het jaartal met 100 of 200 jaar misschien een oplossing? Bedacht me net dat dat ook een oplossing is zonder extra columns

[Megamind]

Inderdaad, sla ze gewoon op als een DATE veld, dan kan je naar het jaar 0 als je wilt.

[Zyppora]

Megamind schreef op woensdag 24 januari 2007 @ 16:07:
Inderdaad, sla ze gewoon op als een DATE veld, dan kan je naar het jaar 0 als je wilt.

Maar wat als je dan als Jezus wilt registreren? Jaartal: -3?

Het kan natuurlijk zo zijn dat TSer een database heeft draaien die DATE/DATETIME niet ondersteunt (al zou ik niet weten welke dat zou moeten zijn).

[ Voor 6% gewijzigd door Zyppora op 24-01-2007 16:11 ]

[posttoast]

Ik draai MSSQL, dus dat is geen probleem. Maar ik vond timestamps juist zo fijn, omdat je er zo lekker mee kunt goochelen en rekenen in PHP.

Ik begrijp nu dus dat het gebruik van timestamps eigenlijk voor prutsers is?

[Verwijderd]

posttoast schreef op woensdag 24 januari 2007 @ 16:27:
Ik begrijp nu dus dat het gebruik van timestamps eigenlijk voor prutsers is?

Ja en php-ers

[frickY]

Er valt ook prima te goochelen met DATE(TIME) velden;
http://dev.mysql.com/doc/...e-and-time-functions.html

[xces]

ik zeg: adodb_time
zoek daarop en je hebt datum/tijd in PHP voor 1970.

[Mafkees]

frickY schreef op woensdag 24 januari 2007 @ 16:06:
Datums sla je op in een DATE danwel DATETIME veld.. niet als Unix timestamp in een int-veld.

Een timestamp is geen int, in MySQL werkt dat iig niet. Dan kom je aan de maximale waarde van een int en een timestamp is groter.

Maar ik ben nu wel benieuwd waarom timestamp eigenlijk geen goede optie is Als ik websites maak in PHP gebruik ik over het algemeen timestamps. DATETIME is dus eigenlijk beter?

[Megamind]

Omdat je met MYSQL DATETIME velden kan manipuleren. Voor een internationale website gebruik ik bijvoorbeeld heel erg veel:

code:

SELECT DATE_FORMAT(CONVERT_TZ(table.date,'+00:00','+01:00'),'%e %M %Y at %H:%i') AS date_formatted FROM table

Dan hoef je niet PHP meer te laten rekenen met je datums

[st18]

Ik heb zelf een methode geschreven die speciaal voor dit soort dingen de datum omzet naar yyyymmddhhmmss (hhmmss heb je niet écht nodig, maar ik heb het optioneel gemaakt). Hij is op deze manier sorteerbaar ook, kunt nog steeds ranges bepalen en berekeningen er mee uitvoeren (daarvoor moet je wel even een paar functies schrijven die dat efficient kunnen).

Je krijgt dan iets van 19420501 en eventueel met tijd, zoals time zelf krijg je dan 19420501161205 zijn minimaal 8 bytes en maximaal 14. Ik gebruik deze manier ipv DATE van een database zelf, omdat ik zelfs bij databases die een slechte DATE support hebben, nog wil kunnen werken met data van voor 1970 op alle machines.

[LauPro]

De discussie INT met timestamp of DATE(TIME) heb ik tijdje terug ook gehad. Uiteindelijk ben ik weer teruggevallen naar een INT met een timestamp. Mijn beweegredenen:
• Het MySQL DATA(TIME) veld heeft eigen syntax, vanuit PHP moet je dus een conversie doen voordat je het in de database kan stoppen.
• Hij het terughalen moet je het ook weer converteren naar timestamps omdat PHP daarmee intern werkt.
• Een database is geen calculator even als een formatteur. Instellen van tijdzones/weergaveformaat is dus iets wat naar mijn idee op applicatieniveau (presentatie) moet gebeuren. En niet op databaseniveau.
• En last but not least; de Unix timestamps werken perfect in alle applicaties die ik tot nu toe heb gebruikt. Ik wil niet het risico lopen dat er ergens door een foute conversie tijden niet meer kloppen of opgeslagen waren in een verkeerde tijdzone. Dit geintje heb ik onder Access namelijk ook eens meegemaakt, niet helemaal te vergelijken, ok.

[ Voor 23% gewijzigd door LauPro op 25-01-2007 13:30 ]

[posttoast]

LauPro schreef op donderdag 25 januari 2007 @ 13:26:
De discussie INT met timestamp of DATE(TIME) heb ik tijdje terug ook gehad. Uiteindelijk ben ik weer teruggevallen naar een INT met een timestamp. Mijn beweegredenen:
• Het MySQL DATATIME veld heeft eigen syntax, vanuit PHP moet je dus een conversie doen voordat je het in de database kan stoppen.
• Hij het terughalen moet je het ook weer converteren naar timestamps omdat PHP daarmee intern werkt.
• Een database is geen calculator even als een formatteur. Instellen van tijdzones/weergaveformaat is dus iets wat naar mijn idee op applicatieniveau (presentatie) moet gebeuren. En niet op database-niveau.
• En last but not least; de Unix timestamps werken perfect in alle applicaties die ik tot nu toe heb gebruikt. Ik wil niet het risico lopen dat er ergens door een foute conversie tijden niet meer kloppen of opgeslagen waren in een verkeerde tijdzone. Dit geintje heb ik onder Access namelijk ook eens meegemaakt, niet helemaal te vergelijken, ok.

Tja, zo zie ik het dus ook een beetje. En dat is balen, want PHP4 + Windows geeft dan gewoon problemen...

[LauPro]

Dan houdt het snel op. De meest nette oplossing is denk ik om een eigen wrapper te schrijven voor die tijdfuncties. Met slim gebruik van offsets kan je wel voor 1970 komen. Stel dat je een class maakt als zoiets:

PHP:

class waTime {
    private $m_year, $m_time;
    
    public function __construct($iBaseTime) {
        // fill in the $this->m_time and calculate the year
    }

    public function getTimestamp() {
        return (60*60*24*365.25*$this->m_year) + $this->m_time;
    }
}

Het is superranzig maar zoals je al zei, je hebt onder win32/php4 geen keus denk ik. En dan is dit nog wel de meest mooie methode omdat je later die class gewoon kan vervangen.

[gvanh]

ik zeg: adodb_time
zoek daarop en je hebt datum/tijd in PHP voor 1970.

Volgens mij is die reactie wat ondergesneeuwd. Toevallig heb ik dit probleem ook gisteren aan de hand gehad ... en dat is inderdaad een perfecte oplossing. Het gaat om een set functies van de AdoDB library. Er is bijvoorbeeld ook adodb_date en nog een aantal standaard datum functies. Werkt perfect en je kunt je standaard werkwijze hanteren. Je hoeft alleen maar een find-replace te doen op de betreffende date-time functies.

[posttoast]

gvanh schreef op donderdag 25 januari 2007 @ 16:37:
[...]


Volgens mij is die reactie wat ondergesneeuwd. Toevallig heb ik dit probleem ook gisteren aan de hand gehad ... en dat is inderdaad een perfecte oplossing. Het gaat om een set functies van de AdoDB library. Er is bijvoorbeeld ook adodb_date en nog een aantal standaard datum functies. Werkt perfect en je kunt je standaard werkwijze hanteren. Je hoeft alleen maar een find-replace te doen op de betreffende date-time functies.

Hey ha, dat is interessant. Maar wat houdt dat AdoDB precies in? Want het is geen standaard PHP-ding zo te zien, en in php.ini kan ik er ook niets over vinden...

Edit: ah, gevonden. Dit is het: http://adodb.sourceforge.net/

Maar eens even kijken wat ik ermee kan. Het nadeel is wel dat ik nu weer iets moet installeren. En dan kun je je af gaan vragen of PHP5 geen optie is.

[ Voor 13% gewijzigd door posttoast op 25-01-2007 16:48 ]

[gvanh]

Installeren is dan wel een groot woord. Het is een kwestie van de adodb map installeren onder je root en dan gaaaan!

[posttoast]

gvanh schreef op donderdag 25 januari 2007 @ 18:00:
Installeren is dan wel een groot woord. Het is een kwestie van de adodb map installeren onder je root en dan gaaaan!

Krijg nou wat, het is echt heel simpel inderdaad! Ik zie dat het ook gebruikt wordt voor database-connections e.d. Het valt misschien buiten de scope van dit topic, maar is dit allemaal zoveel beter dan de standaard spullen van PHP? En zo ja: waarom zit het er dan niet standaard bij?