ugrás a tartalomhoz

php dátum probléma

familyxx · 2010. Aug. 25. (Sze), 22.38
Sziasztok! Apró problémám támad, ami nekem elég hatalmas, de hátha tudja vki a választ.

$actage=50;
$date = date('Y-m-d');
$newdate = strtotime ( '+'.$actage.' year' , strtotime ( $date ) ) ;
$newdate = date ( 'Y-m-d' , $newdate );

Ennek a pár sornak annyi lenne a lényege, hogy az aktuális dátumhoz adjon hozzá annyi évet, amennyi a $actage-ben meg van határozva. Ez működik abban az esetben ha 0 < $actage < ~25 . Ha $actage értéke már 30, akkor a $newdate értéke 1970-01-01 lesz.
Tehát egy bizonyos pontig elbírja, utána már nem bír nagy számokkal számolni.
Légyszi, aki tud segítsen!!!
Üdv
Kori
‹ PHP Excel Reader vs ASCII --> UTF-8 probléma Melyik editor/filemanager-t? ›
 ■
1

32 bit

Poetro · 2010. Aug. 26. (Cs), 00.04
Amennyiben a PHPd 32 bites, akkor a sima date függvények csak 2038 január 19-ig fognak működni, mivel ekkor az előjeles 32 bites szám túlcsordul. Vagy használod a DateTime osztályt (PHP 5.2-től) vagy forgatsz egy 64 bites PHP-t.
2

mktime

DjCsabi · 2010. Aug. 28. (Szo), 07.01
Szia ajánlom az mktime-ot neked, ne bajlódj ezzel.
3

jó tudni...

unregistered · 2010. Aug. 30. (H), 13.29
Na nekem még nem kellett ilyen előre gondolkodom de jó erre felkészülni és inkább elhagyni.
Tehát ha mondjuk 2040-ben lefuttatnám hogy:
echo date('Y-m-d');
akkor ezt kapnám hogy 1970-01-01? Vagy ez csak "számolásnál" jön elő?

Amúgy azt nézem most hogy minden mktime-ban meg adják a date-t is pl így:
echo date("l", mktime(0, 0, 0, 7, 1, 2000));
Most ha ez nem fog működni 2038-től akkor hogy kerül bele a date?
4

igen

solkprog · 2010. Aug. 30. (H), 13.59
Igen 2040-ben 1972-01-01-et fogsz kapni, ha akkor is 32 bites PHP értelmező fogja feldolgozni a kódod. Viszont ha valóban 28 év múlva a szolgáltatód szerverén még 32 bites PHP fog dolgozni, akkor nem ez lesz a legnagyobb bajod...
6

és most?

unregistered · 2010. Aug. 30. (H), 15.00
Szóval akkor most használjam nyugodtan továbbra is a date-t vagy álljak át másra? A phpinfo-ból ki lehet nézni hogy 64-est használnak-e már? De gondolom akkor apache-ból is 64-esnek kell futnia, meg mindenből nem?
64-es php-nak mi a határa? Ugye akkor már nem fogok élni? :D
8

ha

solkprog · 2010. Aug. 30. (H), 15.35
Ha a dátum függvényt csak a jelenidő kiíratására használod akkor használd nyugodtan, de ha már számolgatsz vele is (pl hozzáadsz x évet) akkor gondolkozz el hogy nem-e fog pár éven belül túlcsordulni. És e szerint dönts.
Szerintem ne azt nézd meg hogy x64 van-e a gépen hanem hogy Poetro kódjára nálad túlcsordul-e.
Egyébként nem a "PHP 32bit" határa hanem a megszokott 32bites ábrázolás határa. Gyors számolás után a 64biten tárolt dátum határa 292471210647-es év lesz, szóval szerintem már nem fogsz élni:-)
De ettől függetlenül azt tanácsolom hogy kezdj átállni minden PHP-és függvényről az osztály alternatívájára. Mondom ezt mert a PHP-ét fejlesztőknek az álma hogy a PHP-ét egy teljesen objektum orientált nyelvé alakítsák át. (és gondolom előbb-utóbb megszüntetik ezeknek a függvényeknek a támogatását)
5

Példa

Poetro · 2010. Aug. 30. (H), 14.08
<?php
print mktime(0,0,0, 1, 19, 2038) . "\n";
print date('c', mktime(0,0,0, 1, 19, 2038)) . "\n";
print mktime(0,0,0, 1, 20, 2038) . "\n";
print date('c', mktime(0,0,0, 1, 20, 2038)) . "\n";
?>
kimenet:
2147468400
2038-01-19T00:00:00+01:00

1970-01-01T01:00:00+01:00
Ugyan nem látszik, de a PHP valószínűleg túlcsordult, ezért nem mutatja meg a dátumot.
7

És...

unregistered · 2010. Aug. 30. (H), 15.02
hogy használjam ezentúl pl ezt:
echo date ('Y-m-d H:i:s');
ha a date-t nem használhatom, akkor gondolom ez sem jó megoldás:
echo date('Y-m-d H:i:s', time());
Mindenhol az alternatívában is benne van a date. Ezentúl akkor hogy használjak egy egyszerű dátum/idő kiíratást date nélkül (vagy helyesen)?

Amúgy most ennek csak a 64 bit mizéria az oka vagy van amiért alapból nem ajánlatos a date-t használni?
9

DateTime / DateTimeZone

Poetro · 2010. Aug. 30. (H), 15.44
<?php
print date('c', mktime(0,0,0, 1, 19, 2038)) . "\n";
print date('c', mktime(0,0,0, 1, 20, 2038)) . "\n";

$tz = new DateTimeZone(date_default_timezone_get());
$date = new DateTime('2038-01-19', $tz);
print $date->format('c') . "\n";
$date = new DateTime('2038-01-20', $tz);
print $date->format('c') . "\n";
?>
2038-01-19T00:00:00+01:00
1970-01-01T01:00:00+01:00
2038-01-19T00:00:00+01:00
2038-01-20T00:00:00+01:00
10

hááát

unregistered · 2010. Aug. 30. (H), 15.52
ez mind szép és jó csak az itt a baj hogy előre meg vannak adva a dátumok és időpontok.
Ha én a mai dátumot és aktuális időt akarom kiiratni így: 2010-08-30 16:02:30 akkor azt hogy csinálom meg?
11

További tesztek

Poetro · 2010. Aug. 30. (H), 15.58
<?php
$tz = new DateTimeZone(date_default_timezone_get());
$date = new DateTime(NULL, $tz);
print $date->format('c') . "\n";
print "--\n";
print date('c', mktime(0,0,0, 1, 19, 2038)) . "\n";
print date('c', mktime(0,0,0, 1, 20, 2038)) . "\n";
print "--\n";
$time = mktime(0,0,0, 1, 19, 2038);
print $time . " - " . (is_float($time) ? 'float': 'nem float') . "\n";
$time += 60 * 60 * 24;
print $time . " - " . (is_float($time) ? 'float': 'nem float') . "\n";
print date('c', $time) . "\n";
print "--\n";

$tz = new DateTimeZone(date_default_timezone_get());
$date = new DateTime('2038-01-19', $tz);
print $date->format('c') . "\n";
$date = new DateTime('2038-01-20', $tz);
print $date->format('c') . "\n";
?>

2010-08-30T16:02:22+02:00
--
2038-01-19T00:00:00+01:00
1970-01-01T01:00:00+01:00
--
2147468400 - nem float
2147554800 - float
1901-12-14T16:41:05+00:09
--
2038-01-19T00:00:00+01:00
2038-01-20T00:00:00+01:00
Rövidített változat:
$tz = new DateTimeZone(date_default_timezone_get());
print date_format(new DateTime(NULL, $tz), 'c') . "\n";
12

na neee

unregistered · 2010. Aug. 30. (H), 16.07
1,
Nah szóval erre

$tz = new DateTimeZone(date_default_timezone_get());  
print date_format(new DateTime(NULL, $tz), 'c') . "\n";
ez az eredmény:

2010-08-30T16:12:05+02:00


és nem ez:

2010-08-30 16:12:05


2,
Most tényleg ebből:

date('Y-m-d H:i:s');
ez lett?!

$tz = new DateTimeZone(date_default_timezone_get());  
print date_format(new DateTime(NULL, $tz), 'c') . "\n";
Nem kicsit hosszabb...
13

neígy

solkprog · 2010. Aug. 30. (H), 16.54

$date=new DateTime();
print $date->format('Y-m-d H:i:s');
Lényszíves nézd meg a DateTime osztály manualját, mert a dátum megadása illetve az időzona megadása is elhagyható.
14

najó...

unregistered · 2010. Aug. 31. (K), 15.30
van olyan könyv ami az OOP személéletet adja át szájbarágósan PHP-nél?
15

Ne foglakozz a dátum formátumokkal tárolásnál

whiteman0524 · 2010. Szep. 1. (Sze), 12.11
Legalábbis én nem szoktam. Én mindig úgy dolgozok a dátumokkal hogy az adatbázisban szimpla integer-ként mentem az aktuális time()-ot és ehhez adok hozzá vagy vonok ki belőle ha szükséges. Ebben az a jó, hogy nem kell a hülye formátumokkal meg átalakításokkal foglakozni, simán integerekkel számolsz. Ha kell egy dátum, akkor meg rányomsz egy megfelelő date függvényt és kész is van. Így akár több formátumban is megjelenítheted a dátumokat, anélkül hogy bármit is át kéne alakítanod előtte :) PLusz, gyorsabb is, integerekkel dolgozni mint stringekkel :)

Persze nyilván valóan ennek a "módszernek" is megvan a maga hátránya mint minden másnak úgy általában :) Ha például sok különböző (és itt a különbözőn van a hangsúly) dátumot kell kilistáznod, akkor azokat előtte mindet át kell alakítani emberi "fogyasztársa" alkalmas stringgé, ami ugye sokkal több idő, mint ha eleve stringeket olvasnál ki a db-ből. Tehát valamit valamiért. Vagy a szerver oldali könnyű (és gyors) kezelhetőség mellett voksolsz, vagy pedig a minél gyorsabb megjelenítés mellett :)
16

időzonák

solkprog · 2010. Szep. 1. (Sze), 16.22
azért két plusz hátrányt még leírnék:
1, az egyik hogy ha az időzónával is akarsz foglalkozni akkor problémás lehet.
2, adatbázisban integer típussal problémás (de nem lehetetlen) számolni az idővel (pl hozzáadni x napot).
Persze mindenki úgy használja ahogy neki könnyebb.
17

Valóban

whiteman0524 · 2010. Szep. 1. (Sze), 16.42
Igazad van, talán ezek is hátrányok lehetnek. Én magamból indultam ki - már megint :) - mivel én nem szoktam az időzónákkal foglalkozni. Vagyis eddig még nem volt rá szükségem. Persze ha ezt is figyelembe vesszük akkor ez is hátrány lehet.

A problémás számolás, az megint egy szubjektív dolog. Mert nekem például sokkal könnyebb számokat összeadogatni, mint sztringekkel bajlódni, még akkor is ha mindig el kell játszani, a 60*60*24*etc... fejszámolást :)

De mint mondtad, kinek hogy :)
18

nem egyszerübb így?

solkprog · 2010. Szep. 1. (Sze), 19.08

$DateTime=new DateTime(); 
$DateTime->modify('+1 day');
Most nem egyszerűbb így mint 1283368450-hez hozzáadni 60*60*24-et, majd azt átalakítani 2010-09-02 19:15:10-re?
19

Időszámítás

Poetro · 2010. Szep. 1. (Sze), 19.13
Főleg, hogy ha közben van egy téli/nyári időszámítás átállás, akkor a 60*60*24 nem ugyanazt fogja adni. Mivel a másnap ugyanannyi idő lehet hogy 23 illetve 25 óra és nem 24.