DateTime.Now vs DateTime.UtcNow

Super správička, len by ma zaujímalo:

- keď dostanem DateTime s UtcNow, mám o hodinu menej. Otázka, keď pridám 1 hodinu - malo to byť podľa nášho časového pásma, alebo nie? Dátum som nikdy poriadne nerozumel, je čas sa na to pozrieť.

@siro: ano, je to tak, akurat ako vies, kolko mas pridat? :) zalezi od toho, v akej casovej zone sa nachadzas.

ked do databazy ukladas datetime.now, tak na roznych serveroch to moze byt rozny cas, ake ked tam budes davat datetime.utcnow, tak to bude vzdy ten isty

Uff, chlapi, nerobte hanbu. UTC je cas s informaciou o casovej zone. Ci je utc zistite cez Kind http://msdn.microsoft.com/en-us/library/system.datetime.kind.aspx a na lokalny potom convert cez ToLocalTime http://msdn.microsoft.com/en-us/library/system.datetime.tolocaltime.aspx

To ste nikdy nerobili app cez viac casovych zon?:)

@all tak všade som ukladal cez DateTime.Now a teraz ma serie, že strácam zbytočne výkon :-(((((((

Konvertnúť to nie je problém, ale desiatky riadkov obsahuje DateTime.Now. Na nových projektoch budem ukladať cez UTC, ale pridám hodinu navyše.

@liero: normálne som to zistil DateTime.Now a pod to som dal DateTime.UtcNow - rozdiel bola hodina. Ešte pozriem či aj v robote na serveroch to bude rovnaké a ak hej, tak budem používať UTC + 1 hodina.

Ten čas a pásma to je haluz riadna.

@vlko: neviem, neviem, ci si ku tej hanbe neprispel svojou troskou aj Ty bratm. UTC vo vseobecnosti nema nic s casovou zonou.
Z IT hladiska - triedy ako datetimeoffset, pripadne rozne formaty zapisu casu(xsd datetime, ktory zase vychadza z nejakeho ISO stand.) umoznuju definovat k lokalnemu casu aj informaciou o posune voci utc resp. informaciu o casovej zone.
Cize ak chce niekto pracovat s casovymi zonami resp. roznymi lokalnymi casmi preffered sposob je prave trieda datetimeoffset.(nie henta smelly oldschoolovina, ktoru si sem supol :-)
Inak...kto tvrdi, ze sa nikdy nepopalil na tychto veciach a ze sa vzdy nad tym nepozastavi ked na tieto veci pride po dlhsej dobe...tak ma moj obdiv, u mna plati opak ... dufam, ze to nie je tento pripad :-)))
Co ludi myli (aspon mna - a napisem to jednodychym jazykom) ze Z neznamena, ze to co je pred Z je UTC. To co je pred Z je lokalny cas. To co je za Z je posun voci UTC. Ak je tam len Z bez casoveho posunu tak je to UTC, lebo posun nie je (definovany) ziadny :-)

UTC je čas s informáciou o časovej zóne? No neviem... stále je čas bez časovej zóny, ako každá štruktúra DateTime. UTC je pre jednoduchosť v podstate čas GMT - teda na nultom poludníku. Takže maximálne sa dá povedať, že je to čas s časovou zónou 0, ale žiadnu (inú) informáciu o časovej zóne nemá. Čisto programátorsky: či volám Now(), alebo UtcNow(), dostanem štruktúru DateTime, ktorá nevie nič o časovej zóne, na to slúži štruktúra DateTimeOffset.

ToLocalTime() v podstate spraví to, že k nemu pripočíta/odpočíta príslušné časové množstvo podľa aktuálnej časovej zóny, akú má nastavenú systém. Samozrejme iba ak Kind <> Local - ak už lokálny je, tak nič nie je potrebné.

Ech. T ma predbehol. :)

@Siro: Budeš používať UTC + 1 hodina? A čo zimný a letný čas? ;)

Chlapi, toto je seriozne dost komplikovana tema, ak chceme ist do detailov...

Dobry post napisal Jon Skeet - What's wrong with DateTime anyway? (http://noda-time.blogspot.com/2011/08/what-wrong-with-datetime-anyway.html)

A by to neboli z jeho strany len reci, tak sa dal do portovania Joda time - http://joda-time.sourceforge.net/ - co je asi najznamejsia a mozno aj najlepsia DateTime lib v Java svete do .NETu.

Vysledkom je Noda Time (http://code.google.com/p/noda-time/).

Samozrejme ani rozhodnutie pouzit Noda Time, ci inej podobnej custom DateTime library nemusi byt pre dany typ pouzitia idealne... Vid poznamky na konci Jonovho postu.

No ako som napisal na zaciatku, vec je komplikovana, a tak kazdy musi uvazit, ci sa mu oplati pre jeho projekt nie je naozaj vyhodnejsie jednoducho pisat "DateTime.Now" a neriesit nic dalsie, alebo ist do tychto not-easy veci.

Co sa tyka DateTime triedy v BCL - stale su celkom uzitocne best practices z MSDN - http://msdn.microsoft.com/en-us/library/ms973825.aspx.

-- s.

@S(a)tano: však sa pýtam, či keď pridám 1 hodinu čo je to v poriadku alebo nie, myslel som si - že to také jednoduché nebude.

Otázne je, že keď zavolám UtcNow a použijem ToLocalTime či to bude efektívnejšie ako Now.

Ď.

@Siro: Len tak si pripočítať 1 hodinu v poriadku nie je.

Osobne verím, že pri väčšine aplikácií nie je dôvod používať UtcNow namiesto Now kvôli výkonu. Meverím že nárast výkonu bude dostatočne citeľný (ak vôbec).

Pracovať s UTC časom by si mal, ak robíš kalkulácie nad DateTime dátami (pripočítavaš/odpočítavaš nejaký čas...). Pretože ak to budeš robiť v lokálnom čase, môžeš dostať nesprávny výsledok práve kvôli zimnému a letnému času - viď "Best Practice #3" v tom MSDN odkaze čo dal Slavo.

a tak ma napadlo. nebolo by predsalen rýchlejšie dať .Now a neriešiť veci okolo? :) či toto je presne ten bottle neck ktorý vám vašu appku dáva dole? :) nemyslím si.

Bez UTC casu a casovych zon sa nezaobides. Ide o to, ze ak v aplikacii pouzivas Datum a nie len casove inervaly, nedokazes pre ludi z roznych casovych pasiem zobrazovat korektne datumy.

tento kod mi zbehol vzdy za tri milisekundy. Neviem si predstavit scenar, kedy by datetime.now mohol sposobil nejake spomalenie.

Console.WriteLine(DateTime.Now.Millisecond);
for (int i = 0; i < 1000; i++)
{
var time = DateTime.Now;
int a = 0;
for (int j = 0; j < 10; j++)
{
a += i;
}
var time2 = DateTime.Now;
var span = time - time2;
var c = span.TotalMilliseconds + 1;
}

Console.WriteLine(DateTime.Now.Millisecond);
Console.ReadKey();

@slavof:
ak si chcel poukazat na to, ze ani DateTimeOffset nie je odpovedou na vsetky mozne problemy hlavne pri vypoctoch tak suhlasim.(ale ani konvert do UTC vypocet a spatny konvert do lokalneho casu). Ale toto su pomerne zname veci.

Uz jsem to kdysi resil:

http://blog.vyvojar.cz/mstr/archive/2010/11/20/bud-ek-dle-apple-aneb-pracujeme-s-datem-a-asem.aspx