Dibi a autodetekce typů – formatovani casu

llsm · před 7 lety

Zdravim, do ted jsem pouzival v dibi autodetekci casovych formatu. A ted me trochu prekvapilo, ze rozlisuje jen date, datetime a timestamp. Hodilo by se mi k nemu pridat i Time. Dibi totiz jinak Time prevede na dateTime a zobrazuje cas s aktualnim datem. Koukal jsem, ze se po tom nekdo pidil v dobe, kdy toto rozlisovani typů byla novinka, ale asi to zapadlo…

Milo · před 7 lety

Nepomůže si nastavit formát na H:i:s?

llsm · před 7 lety

Tak pravdepodobne to tak skonci, ale je takove slabsi, ze ma clovek v databazi time, dibi z toho udela datetime a ten pak budu zase zpet formatovat jen na time. Ale rozhodne to pro me neni nejaky zasadni problem…

David Grudl · před 7 lety

Je to kvůli tomu, že PHP žádný objekt reprezentující čas nativně nemá.

llsm · před 7 lety

David Grudl napsal(a):

Je to kvůli tomu, že PHP žádný objekt reprezentující čas nativně nemá.

Chápu, ale neměla by se databázová vrstva řídit možnostmi databáze a ne prostředků, které využívá?

Milo · před 7 lety

llsm napsal(a):

David Grudl napsal(a):

Je to kvůli tomu, že PHP žádný objekt reprezentující čas nativně nemá.

Chápu, ale neměla by se databázová vrstva řídit možnostmi databáze a ne prostředků, které využívá?

Já bych možná převod samotného času bez datumu na DateTime úplně odstranil a nechal ho jako string. Stejně jde ve výsledku (resp. jsem nikdy nic jiného nepotřeboval) jen o formátování na HHH:MM:SS a to databáze dodá sama.

Ostatně to lze udělat i ručně $result->setType('colName', dibi::STRING).

David Grudl · před 7 lety

To není tak úplně pravda, někdo preferuje zápis 10:00 p.m., někdo 22:00 a někdo 22.00.

jahudka · před 7 lety

Zdravím vespolek,

vau, teda ohnout si dibi aniž by člověk sáhnul přímo do jejího kódu spíš víc nejde než jde se mi zdá…

Narazil jsem na tuhle podivnost s „TIME“ sloupcema a po přečtení tohohle threadu jsem si říkal: jo, škoda že PHP nemá žádnou nativní knihovnu na práci s časem (bez data). A pak si říkám: no tak si ji napíšu. Jak řekl, tak učinil, a pak až mě napadlo se podívat, jestli to dibi dokážu nějak vnutit.

Ve zkratce: abych mohl profiltrovat jeden datovej typ trošku jinak než to normálně dělá dibi, musím podědit DibiConnection, DibiResult a DibiColumnInfo.

Ale jinak mám dibi opravdu rád :o) a doteď jsem jí takovouhle kulišárnu nikdy neprovedl! ^_^

EDIT: Aha, a stejně jsem s tímhle nahranej, protože přinejlepším dokážu to, že mi dibi na moje TIME nebude sahat, ale obalit si ho svou vlastní třídičkou už budu pak muset zase manuálně… :o/ tyjo to je ale nahouby… nemáte někdo nějaký zázračný řešení?

Editoval jahudka (29. 9. 2012 4:04)

jahudka · před 7 lety

A jeste jsem narazil na jednu vec ktera mi prijde podivna:

Vkladani casu do DB pomoci modifikatoru %t se snazi vzdycky vlozit kompletni datum a cas – i kdyz treba vlozim string „HH:MM“, dibi si ho prevede na DateTime a ten pak zformatuje jako YYYY-MM-DD HH:MM:SS. Tak si nejsem uplne jistej co pak udela MySQL kdyz do „TIME“ sloupce chci vkladat cely „DateTime“ – nejspis to funguje, ale chova se to opravdu 100% tak jak ma?

Osobne bych navrhoval oddelit date, time a datetime uplne a nabidnout nejakou moznost nastavit jak se s tim ma pracovat.. tak jak ted jde nastavit vlastni formaty pro date a datetime, ale idealne by myslim mohlo jit nastavit jako „format“ i callback, kterej by to filtrovani mohl obstarat a na jeho vystup uz nesahat.. a pak mit treba modifikator %d na date, %t na time a %dt na datetime (nebo neco jako %d, %ti a %t kvuli zpetny kompatibilite).

Neco bych napsal, ale jednak nedelam s gitem, takze nevim jak udelat pullrequest (ani poradne nevim jestli to co bych mel udelat je pullrequest) a hlavne si nejsem uplne jistej jestli bych dokazal navrhnout dostatecne kvalitni a obecny reseni..

Oznámení

Dibi a autodetekce typů – formatovani casu