24 odpovědí na toto téma

[mpik]

Už jsem nějaký čas v Pascalu nedělal, ale vím, že jsem to řešil. IncMinute tam nevidím. No, přinejhorším, TDateTime je jen Double, obsahuje počet dní od roku 1899 (?) a za desetinnou tečkou části dne. Mělo by tedy stačit odečíst 1/24. Ale ona tam určitě na to funkce je, nebo se dá snadno nadefinovat.

[MaFa]

MaFa: z hlediska skriptu jiz funguje, ale ted to haze zase o 2 hodiny zpet, tzn. realny nalez 23:15 posune na 22:15.

A mas spravne nastavene casove pasmo na svem pocitaci? Musis si nastavit nejenom casovou zonu, ale i letni cas!

[S474N]

Na pocitaci se systemem Win7 opravdu nic takoveho neresim. Nicmene jsem se dival a vse je spravne. Coz o to, ono to i odpovida +1 hod je dle pasma +1 hod letni cas, tedy celkem +2 hodiny.

[HaLuMa]

Nasli jste pouze zdanlive reseni. Tedy takove, ktere se vam ted jevi, ze funguje, nicmene neni uplne spravne. Spravne by bylo, kdyby se prepocitaval cas na UTC ne z lokalni zony, ve kterem je vas pocitac, ale z lokalni zony, ve ktere lezi ta konkretni nalezena keska. Ta totiz muze byt v uplne jine zone! GPSka v sobe ma informace o casovych zonach, takze podle polohy dokaze prepocitat cas na UTC. Geoget to ale nedokaze. (zatim - je to zajimavy namet na vylepseni.) Takze zatim lze jen tupe predpokladat, ze nalezy jsou ve stejnem casovem pasmu, jako vas pocitac, a spravne uvest cas, nejlepe tim prepoctem do UTC. Ted se tam, skutecne moji chybou, zadava lokalni cas, ale oznacuje se jako UTC. Ono je to dano tim, ze drive cas nalezu Groundspeak nezpracovaval, nyni ho ale ve svych internich databazich uchovava. Bohuzel ale v jeiich lokalnim casovem pasmu, a ne vzdycky pak provadi spravnou konverzi do uzivatelova lokalniho pasma. A tim vznika spousta dalsich problemu...

[MaFa]

Jinymi slovy rikas to co jsem tu psal uz "6.07.2012 19:30.". Hlavni problem je, jak udrzovat databazi casovych zon aktualni. Meni se totiz pomerne casto. Mozna by slo vyuzivat nejakou webovou sluzbu, nakonec tech statu na jedno logovani nikdy nebude moc.