vervaldatum download bare producten

[judian]

als ik de verval datum te hoog invul dan komt er 1970-01-01 te staan. en dan is voor de klant natuurlijk de download verlopen. als ik hem leeg laat in begin met invullen dan slaat die de download niet op.
en kan ik hem dus opnieuw toevoegen. dus ik ben verplicht een datum in te vullen voor ik iets kan opslaan.
als ik hem opgeslagen heb met een datum van 2030 of zoiets dan werkt het wel.
vreemde is wel dat als ik de datum dan weer weg haal er weer 1970-01-01 komt te staan.
een datum van 3000-01-01 dat lukt hem niet om toe te voegen.
ik weet dat 2030 nog lang gaat duren maar ik wil niet nu alle producten toevoegen. en dan rond die geest weer alle datums aan te passen.

ik heb eens gekeken rechtstreeks in de database en kwam tot ontdekking dat als ik 4000-01-01 invul die ook zo daar komt te staan. alleen er komt op de site weer 1970 te staan waar ik een product toevoeg en verander.

alleen als ik dan een order plaats dat komt er te staat datum vervallen en kan ik het product niet downloaden.

dus data opslaan gaat goed. de waarde uit de database pakken gaat verkeerd. getal is te hoog te laag en kun je niet downloaden.

bij backoffice de verval datum leeg maken laat hem niet in de database opslaan en blijft dus de datum die al in de database stond staan.

ik ben gaan kijken in get-file.php in de prestashop map en kwam het volgende tegen.

$now=time();
exit($now); is leeg
$product_deadline = strtotime($info['download_deadline']);
exit($product_deadline); is leeg
exit($info['download_deadline']); is 2011-10-06 02:27:15
$customer_deadline = strtotime($info['date_expiration']);
exit($customer_deadline); is leeg
exit($info['date_expiration'] ); is 4000-01-01 23:59:59


ok nu de code waar die op vast gaat lopen.

if ($now > $customer_deadline AND $info['date_expiration'] != '0000-00-00 00:00:00')

displayError('Expiration date exceeded');

echo strtotime("2038-01-01 23:59:59"); is 2145999599

echo time(); is 1309228374
echo strtotime("2039-01-01 23:59:59"); is niks nada geen echo

dus daar loopt die op vast. php heeft nog 28 jaar om dat probleem op te lossen. hahahaha

strtotime gaat namelijk niet verder dan 2038.

dus moeten we het op een andere manier oplossen.

$now=date("Y-m-d H:i:s", time()); ipv $now=time();

om te controleren wat het vandaag is.

$customer_deadline = $info['date_expiration']; ipv $customer_deadline = strtotime($info['date_expiration']);

om mee te controleren.


jep veranderd in de code en geen foutmelding meer.


verder zal er nog wel een bug zitten in het cms backoffice systeem die een verkeerde datum weer geeft en niet opslaat als de datum niet ingevuld wordt.
graag zou ik in de volgende update een optie zien om de verval datum helemaal als optie te kunnen negeren. niet dat mijn website ooit het jaar 4000 gaat halen. lol

[judian]

<?php echo ($productDownload->id > 0) ? ((!empty($productDownload->date_expiration) AND $productDownload->date_expiration != '0000-00-00 00:00:00') ? date('Y-m-d', strtotime($productDownload->date_expiration))
: '' ) : htmlentities(Tools::getValue('virtual_product_expiration_date'), ENT_COMPAT, 'UTF-8') ?>"

dit zit in adminproducts.php


en is vervangen door

<?php echo ($productDownload->id > 0) ? ((!empty($productDownload->date_expiration) AND $productDownload->date_expiration != '0000-00-00 00:00:00') ? substr($productDownload->date_expiration,0,10)
: '' ) : htmlentities(Tools::getValue('virtual_product_expiration_date'), ENT_COMPAT, 'UTF-8') ?>

nu wordt de verval datum gewoon normaal uit data base gehaald. en heb je ook niet steeds probelemen met opnieuw opslaan.

[judian]

het is met tweede post goed tot een jaar of 9999-12-31 23:59

wil je het oneindig gebruiken zou ik

substr("119999-12-31 23:59",0,strlen("119999-12-31 23:59")-6);

gebruiken. lol

[judian]

hoe zit dat eigenlijk met am en pm met programmeren?