Cloud as a Story - Vunvulea Radu

Intr-un post anterior am povestim putin despre TimeZone si daily light saving. Prin metoda "IsDaylightSavingTime" a unui TimeZoneInfo spuneam ca se poate verifica daca pentru o anumita data avem ora de vara sau de iarna. Lucrurile se complica putin cand nu cunoastem TimeZoneInfo pe care il are clientul. In acest caz, pe baza orei trebuie sa identificam pe ce time zone se afla clientul. Acest lucru nu se poate determina in totalitate, dar putem identifica un time zone care partial asemanator. Un obiect de tip TipZoneInfo contine metoda "GetAdjustmentRules" care ne returneaza o lista de reguli care se folosesc pentru a ajusta ora (de exemplu ora de vara sau de iarna). Fiecare regula defineste perioda de inceput si de sfarsit dar din pacate perioada nu este definita la nivel de zi ci doar de luna. De exemplu ni se specifica ca in luna martie se termina perioada in care se aplica regula, dar nu se specifica data exacta cand aceasta se termina. A doua problema apare in ...

Foarte multi dezvoltatori s-au lovit de problema legate de datetime si offsetul timpului in functie de locatie. Daca avem o data si vrem sa verificam daca pentru aceasta data daylight saving este activ sau nu putem sa verificam folosind metoda IsDaylighSavingTime. TimeZoneInfo.Local.IsDaylightSavingTime(DateTime.Parse("01/04/2012")) Aceasta metoda o sa ne returneze TRUE daca daylight saving este activ pentru data respectiva. Trebuei avut grija ca in functie de locatia de pe glob dayling saving poate sa inceapa sau sa se termine intr-o zi diferita. Odata ce ne-am setat current culture pe cultura dorita am avea si daylight saving time setat pentru zona respectiva. Thread.CurrentThread.CurrentCulture = myCulture; Thread.CurrentThread.CurrentUICulture = myCulture; TimeZoneInfo.Local.IsDaylightSavingTime(DateTime.Parse("01/04/2012")) Dar o sa avem o surpriza neplacuta. TimeZoneInfo.Local o sa ne returneze timezone-ul local a masinii si nu cel pe care noi l-am setat prin ...

Zilele astea m-am trezit cu niste probleme la o aplicatie la care am lucrat impreuna cu niste colegi. Formatul la ora nu era consistent in toata aplicatia. In unele locatii aparea sub forma 04:50, iar in alte locatii aparea sub forma 16:50. Problema principala a fost ca s-a folosit formatarea fara a se cunoaste exact ce se afiseaza cand se foloseste HH sau hh. Mai jos as vrea sa ne uitam la metoda ToString a unui DateTime. Aceasta primeste ca si parametru un string prin intermediul caruia se poate specifica modul de formatare a datei. yyyy - o sa afiseze anul in formatul 2012 MMMM - luna in litere( iulie, august, ...) MM - luna in cifre( 07, 08) dddd - ziua din saptamana in litere( luni, marti) ddd - ziua in litere dar prescurta dd - ziua curenta din luna( 20, 31, ...) H - ora in format 24, iar daca ora e mai mica ca 10 se va afisa o singura cifra, fara 0( 1, 2, 14) HH - ora in format 24, iar daca ora e mai mica ca 10 se va afisa un 0 la inceput( 01, 02, 14) h - ora in format AM/PM, ia...

Care este greseala in codul de mai jos: for(DateTime date=beginDate;date<=endDate;date.AddDays(1)) { // Executa cod. } Problema apare in for, unde date va fi mereu mai mic ca endDate . Cauza este AddDays, care nu adauga la data curenta o anumite valore ci returneaza o noua data. Nu trebuie sa uitam ca DateTime este un value type. Codul corect este: for(DateTime date=beginDate;date<=endDate;date = date.AddDays(1)) { // Executa cod. }