dotNETportal.cz

Potřebuji ve své aplikaci pracovat s řadou různých podob Datumů (načítání ze souborů jako String) a tak bych si chtěl udělat nějaký vlastní Parser.

Ne vždy totiž při načítání dat vím, v jakém formátu je datum zapsán.

Uvažuji, že bych si udělal textový soubor s možnými formáty (např. yyyyMMdd, ddMMyyyy) a potom v cyklu tyto varianty procházel jestli se podaří převod na datum (šlo by snadno formáty přidávat).

Rád bych se poradil, jestli není nějaké elegantnější řešení.

Předem děkuji

Jenže:

1. já potřebuji převádět datum na řadě míst programu a těch formátů může být docela hodně (řádově 10-20) a dopředu všechny neznám.

2. pokud používám pokus o převod datumu, může se tato operace hodněkrát opakovat (načítám tisíce řádků a co řádek to datum)

Používám tam řešení, že pokud načítám velké množství řádků (bude formát datumu u všech stejný) pokud se mi podaří převod, u následujícího řádku již používám hodnoty formátu z předchozího úspěšného převodu, abych opakovaně nezkoušel všechny formáty.

Jsem stále ještě v progr. velký začátečník a tak se občas radši zeptám, jestli nejdu špatným směrem.

Každopádně vyzkouším jestli pomocí TryParse to převede všechny mě prozatím známé formáty (které se mohou u mě vyskytnout).

Protože je v některých případech pořadí den měsíc jinak než DateTime.TryParse dokáže napřímo přečíst (bez přidání definice formátu) znamená to, že stejně musím použít vlastní definice formátů a ty procházet v cyklu.

Dále, dopředu nevím jaký formát se může vyskytnout a potřebuji aby uživatel mohl tento formát snadno přidat do seznamu. Tím pádem mi přijde asi skutečně nejlepší uchovat formáty v nějakém txt souboru a použít vlastní třídu na řešení převodu datumu.

V tom případě by mě zajímalo, jak vyřešíte například znamená-li "1/3/2008" 1. března 2008 nebo 3. ledna 2008...

Vzhledem k tomu, že pracuji vždy s větším množstvím datumů (řekněme min. tisíce řádků/výskytů), chybné řešení se vyloučí pokud těch datumů mám více za sebou. Ale uznávám, že je to komplikace se kterou je třeba počítat a díky za upozornění.

Bez většího počtu výskytů datumů to samozřejmě není možné rozhodnout.

Nezlobte se, ale prijde mi ze to jenom zbytecne komplikujete. Rekl bych ze shudnejsi bude nez delat vlastni tridu na 50 000 zpusobu jak naformatovat cas, spis sjednotit casy ktere mate na standartni a navazovat dalsi zaznamy stadartne ....

Jenže ty soubory s datumy nejsou vytvořené mou aplikací, ale slouží jako zdroj dat a ještě k tomu mohou pocházet z různých programů (od různých výrobců). Takže já se musím přizpůsobit těmto různým souborům.

Ano, použil jsem nakonec v podstatě metodu TryParseExact a v cyklu dosazuji předefinované formáty. Respektive jsem použil ParseExact v bloku Try. Pokud se převod podaří, projde se rovnou přes následující řádky kódu s tím, že mám již požadovanou návratovou hodnotu datumu.

V mém případě se většinou jedná o docela velké soubory a časové období bývá větší takže pravděpodobnost špatného rozeznání datumu je docela malá.

Pokud by i přes to tento problém nastal myslím, že jediným řešením je stejně interakce uživatele. Stačilo by potom v seznamu předefinovaných formátů změnit jejich pořadí jak jdou za sebou.

děkuji všem za příspěvky

Díky za upozornění zkusím.

Ono je to tak, že pokud se převod podaří, používám již přímo jen tento formát a dále neprocházím varianty v cyklu. Nicméně jsem i tak blok Try zachoval a tak to vyzkouším bez něj za použití TryParseExact.

Mimochodem když už jsme u Try ... Catch doporučili by jste řešení bez něj a ošetřit to řekněme řadou kontrol na správnost hodnoty (pomocí If) nebo v případě náročnějšího ověření blok zachovat. Ono je to totiž někdy docela náročné, správně hodnotu ověřit.