Každý chce neustále vědět, jaké změny musí v aplikaci učinit, aby běžela v cloudu, v tomto případě na Windows Azure. Jsou ale věci, které vám žádný návod neřekne, a musíte si je protrpět sami, stejně jako jeden z našich partnerů, který níže popsané zaznamenal.

Měl aplikaci, která musela přestat sbírat data v přesně stanovený čas, řekněme něco jako aukce. Ale nepřestala. Sbírala dál, a to ještě 2 hodiny poté. Důvod je celkem triviální, naprosto logický, ale snadno přehlédnutelný. Všechny aplikace, které dosud psali měli server i klienty ve stejné časové zóně (aniž by o tom někdo takto přemýšlel). Pokud si dáte na svém počítači DateTime.Now a DateTime.UtcNow, budou se o 1-2 hodiny lišit podle letního či zimního času. Ve Windows Azure ale běží všechny servery v UTC čase, takže tento rozdíl je na serveru vždy 0, ne však na klientovi. Čas na klientovi z ČR je tedy o 1-2 hodiny jiný než čas na serveru.

Dá se z toho vybruslit různými způsoby:

  1. nejčistší, ale ne moc komfortní je u všech časových údajů zároveň uvádět i časové pásmo, pro které údaj platí, neboť čas na hodinkách sám o sobě je nedostatečný údaj pro určení astronomického času.
  2. pokud víme, že na server přistupují klienti z jediného časového pásma, je možné to řešit konfigurovatelnou korekcí času (jenom pozor, že v létě je jiná než v zimě)
  3. je možné se pokusit o auto-detekci zóny např. tím, že JavaScript na klientovi zjistí aktuální čas a pošle ho v nějakém skrytém poli na server

Všechny 3 možnosti je možné považovat jako zbytečnou otravu. Na druhou stranu kouzlení s časovými zónami je denní chleba všech našich amerických kolegů, o ruských nemluvě. Globální datová centra do tohoto problému chtě nechtě zatáhnou i nás z našeho malého IT rybníčku.