tiny ‘n’ smart
database layer

Odkazy: dibi | API reference

Oznámení

Omlouváme se, provoz fóra byl ukončen

modifikátor %d

před 10 lety

Karel_
Člen | 5

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í

před 10 lety

phx
Člen | 652

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.

před 10 lety

kravčo
Člen | 723

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', '
');

před 10 lety

paranoiq
Člen | 388

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

před 10 lety

Karel_
Člen | 5

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á

před 10 lety

phx
Člen | 652

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)

před 10 lety

LM
Člen | 206

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.

před 10 lety

Karel_
Člen | 5

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“

před 10 lety

paranoiq
Člen | 388

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

před 10 lety

Karel_
Člen | 5

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?

před 10 lety

LM
Člen | 206

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)

před 10 lety

David Grudl
Nette Core | 6806

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í.

před 10 lety

Karel_
Člen | 5

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