modifikátor %d

Karel_ · před 10 lety

Zdravím všechny,
myslím si, že by bylo lepší, kdyby se modifikátor %d choval standardně pro všechna data, kupříkladu dotaz („select * from tabulka where datum = %d“, ‚1900–01–01‘) se mi transformuje do select * from tabulka where datum = ‚1970–01–01‘ To podle mne zkrátka není očekávané chování, podobně se chová i helper date v šablonách Nette, ale tam bych to skousnul, nabízí se sice výměna %d za %s, ale jistě by bylo nepříjemné zjištění, že se vám určitá část záznamů zkrátka vložíla špatně, protože jste předpokládali nějaké chování

PS: jinak dibi je fakt fajn, velice se mi líbí

phx · před 10 lety

Toto chovane je zpusobeno tim, ze funkce pro prevod pouziva timestamp, kde 0 = 1.1.1970.

Resenim by bylo funkci prepsat bez pouziti timestamp, ale to by bylo velice narocne. %d je unikatni v tom, ze nezalezi v jakem formatu se ji data predaji.

Osobme si myslim, ze krome historickych databazi (napr prehled kniz z minuleho stoleti) tento problem nevadi.

kravčo · před 10 lety

Dátum 1. január 1900 nie je možné reprezentovať 32 bitovým unix timestampom, ktorý interne používa dibi. Zjednodušene, treba sa zmestiť do rokov 1902–2037.

dibi::test('
    SELECT *
    FROM [tabulka]
    WHERE [datum] = %d', '1902-01-01', '
');

paranoiq · před 10 lety

nebylo by na čase, aby dibi přešlo z integeru na DateTime? (PHP 5 >= 5.2.0)

Karel_ · před 10 lety

phx napsal(a):

Toto chovane je zpusobeno tim, ze funkce pro prevod pouziva timestamp, kde 0 = 1.1.1970.

Resenim by bylo funkci prepsat bez pouziti timestamp, ale to by bylo velice narocne. %d je unikatni v tom, ze nezalezi v jakem formatu se ji data predaji.

Osobme si myslim, ze krome historickych databazi (napr prehled kniz z minuleho stoleti) tento problem nevadi.

Ano, já vím, že je to tím, ale právě takovou databázi provozuji, víš jak bych z toho byl těžce na mrtvolu, kdybych to opomněl a všim si toho tak po půl roce? :-D Jinak ono na tom trochu záleží, mi to takové klasické datum ve formátu d. m. yyyy nezchroupalo, z toho důvodu jsem si to původně i přepsal v Nette, ovšem máš pravdu, že taková „stará“ data jsou méně častá

phx · před 10 lety

Osobne jsem kdysi (v dobach bez dibi a nette) pouzival svoje funkce, ktere prevadeli ceske datum (dd.mm.yyyy) na MySQL format (yyyy-mm-dd) a zpet za pomoci prace s retezci. Coz ale neni univerzalni.

Otazka zni jake vsechny formaty jsou mozne?

timestamp
dd.mm.yyyy (cz)
mm/dd/yyyy (uk,us,…)
ddmmyyyy
yyyymmdd
?? nevim

A ona fce by tohle vsechno musela sama sama prevest.

Nebo v PHP5 na to jiz neco existuje? (zminovany DateTime – musim se podivat)

LM · před 10 lety

Na 64bit by měl fungovat i negativní timestamp, DateTime tohle ale neřeší ne? více méně to je jen obal nad strtotime a spol.

Karel_ · před 10 lety

phx napsal(a):

Osobne jsem kdysi (v dobach bez dibi a nette) pouzival svoje funkce, ktere prevadeli ceske datum (dd.mm.yyyy) na MySQL format (yyyy-mm-dd) a zpet za pomoci prace s retezci. Coz ale neni univerzalni.

Otazka zni jake vsechny formaty jsou mozne?

timestamp

dd.mm.yyyy (cz)

mm/dd/yyyy (uk,us,…)

ddmmyyyy

yyyymmdd

?? nevim

A ona fce by tohle vsechno musela sama sama prevest.

Nebo v PHP5 na to jiz neco existuje? (zminovany DateTime – musim se podivat)

Já bych spíš položil otázku, které formáty jsou používané. Jak píšeš, vytvořil si fce na převod mezi dd.mm.yyyy a yyyy-mm-dd, což je myslím docela častý případ použití, osobně si myslím, že v našich podmínkách snad nejčastější, proto je sice pěkné, že ta funkce „umí hodně“, přesto co s tím, když to nepotřebuju? Jestli jde o univerzálnost, kdyby šlo o C++ bylo by na místě vytvořit typ Date s nějakou metodou toString a fromString, kdyby byly protected, nebyl by myslím velký problém si připsat „své oblíbené toString fromString“

paranoiq · před 10 lety

LM napsal(a):

Na 64bit by měl fungovat i negativní timestamp, DateTime tohle ale neřeší ne? více méně to je jen obal nad strtotime a spol.

od nějaké verze funguje negativní timestamp i v PHP na 32bitu, ale to jsme stále omezeni na 1970 ±68 let

DateTime je v PHP bohužel až od verze 5.2.0. úprava by byla triviální, ale otázka je zda dibi nechce podporovat i nižší verze PHP

Karel_ · před 10 lety

PHP rozumím asi jak koza petrželi (s tím rozdílem, že mně moc nechutná), ale není možné využít něco jako podmíněnou kompilaci, sice, že by se vlastně vytvořil alternativní kód pro různé verze PHP?

LM · před 10 lety

paranoiq napsal(a):

od nějaké verze funguje negativní timestamp i v PHP na 32bitu, ale to jsme stále omezeni na 1970 ±68 let

DateTime je v PHP bohužel až od verze 5.2.0. úprava by byla triviální, ale otázka je zda dibi nechce podporovat i nižší verze PHP

DateTime skutečně umí i pod 1902, to jsem netušil. Dibi zdá se chce být kompatibilní s PHP 5.1, ale tohle je možná důvod vyžadovat PHP 5.2 v nových verzích.

Editoval LM (20. 8. 2009 14:56)

David Grudl · před 10 lety

Zkusil jsem dibi přepsat tak, aby interně používalo DateTime (pokud je třída dostupná). Nicméně zvenčí začít místo timestampu vracet DateTime by byla drsná změna API, takže to bude i nadále vracet timestamp nebo řetězec v daném formátu. Nicméně pokud se jako formát uvede TRUE, vrátí to objekt DateTime.

Prosil bych o otestování.

Karel_ · před 10 lety

Velice se mi to líbí, zvláště oceňuji, že to v případě selhání nyní namísto data 1970–01–01 vyhodí Exception, tomu říkám korektní chování :-) Jako zajímavost bych uvedl, že 29. únor se interpretuje u nepřestupných let jako 1. březen, ale to si nestěžuji, důležité je, že co jsem zkoušel různá data, pracuje to dle očekávání :-)
Díky mnohokrát

Oznámení

modifikátor %d