
Změna na čárku by bohužel vadila.
Jinak děkuji za alternativy, nějaké použiji, ale stejně je to na palicu, že to spočítá špatně :-)

můžeš to uložit v OF2003 ?

Netvrdím, že Excel nemá chyby, ale v tomto případě se musím zastat, jelikož se až přemírně snaží o standardní v popisech popsané převody. Datumy - 3x pozor na ně nejsou to texty, jsou to čísla a pracuje se s nimi jako z čísly!! Zadáte-li 3.11 a 3.11.11 je to de fakto resp. dle popisu excelu vždy 3. listopad 2011. Tedy přestože to máte text tak buňka je vždy dle řeči makra dim as variant a neví zda se jedná o text nebo datum a sečte je dohromady. Toto je problém převodu z textových souborů z netu, kdy nedáte formát, pořád je u čísel s desetinnou tečkou zobrazují pokud to je přípustné datumy. Velké varování to co vypadá jako datum a není datum je nebezpečné pro jakékoli úkony raději tam dejte něco písmeno, pozor i "/" je datum.

Jenže já formát 3.11.11 neovlivním, protože je to označení které používájí stovky lidí a je ve smlouvách atd. Takže tudy cesta nevede.
To že se to snaží převést na datum chápu (i když zadávám schválně formát buňky text nacož excel kašle)
Co je ale divné, že třeba 3.03.03 a 3.03 si neplete, i když by to taky mohlo být 3.3.2003. Prostě to dělá dobře až na čísla končící x.11.11 a to už je podle mě nekonzistentní a tudíž přinejmenším divné chování.

Pro naprosté upřesnění 3.03 je 3. březen 2011,3.03.03 je 3. březen 2003 jsou tudíž naprosto různé, v roce 2012 bude fungovat 3.11 a 3.11.11, neboť se jedná znovu o různé datumy. Věřím, že je to již jasné 3.03 je 3. březen právě probíhajícího roku!! Je to chyba analytika, já bych vzledem k Excelu nikdy takovou strukturu identifikace neodsouhlasil, ono už jen napsat toto v exceĺu je umění. Výhoda je, že to máš jako text a ne jako někdy datum někde text. proto změň všechny tečky za nic a máš čísla, která jsou jednoznačná a budou spolehlivě fungovat. Jen ta změna je nesystemová.