LogParser, UTC czy jakiś inny?

Tak w formie marudzenia. LogParser jest doskonałym narzędziem, ale czasami bywa irytujący. W sumie może nawet nie tyle sam LogParser , co te wszystkie dziwne strefy czasowe, czasy letnie/zimowe i inne tego typu wynalazki.

Skorelowanie ze sobą zdarzeń jest istotne, a czas jest jednym z atrybutów zdarzenia, po którym owa korelacja może nastąpić. Jeśli wykorzystany jest LogParser w sposób opisywany w serii o tamagotchi, warto rzucić dokładniej okiem na to, jaki czas jest podawany. Konkretnie dla przypadków (formatów wejściowych):

Format EVT

W formacie EVT występują dwa timestampy:

Oba są prezentowane w local time. Nie ma możliwości zmiany poprzez parametr wejściowy dla tego formatu. Oczywiście nie jest to wielki problem, ponieważ istnieje funkcja TOUTCTIME_ , która przy konwersji z czasu lokalnego do czasu UTC uwzględnia strefy czasowe oraz czas letni/zimowy.

Format REG

Tutaj występuje jeden timestamp: LastWriteTime , który występuje (na odmianę) w formacie UTC. To oczywiście nie jest również problem, ponieważ istnieje (niespodzianka) funkcja TOLOCALTIME_ , analogiczna do funkcji TOUTCTIME_.

Format FS

Tu jest większa zabawa. Po pierwsze istnieje parametr wejściowy dla tego formatu: useLocalTime , który jest domyślnie ustawiony na wartość ON , co oznacza, że wszystkie timestampy wyświetlane są w czasie lokalnym. W tym przypadku jest ich więcej, bo istnieją aż trzy znaczniki:

Oczywiście wszystkie te wartości zostaną podane w czasie UTC jeśli parametr useLocalTime zostanie ustawiony na OFF.

I taka refleksja – czy nie można było tego zrobić spójnie? Może wszystkie te formaty mogłyby używać czasu UTC/lokalnego i dla każdego z tych formatów mógłby istnieć parametr useLocalTime? A tak to trzeba pamiętać...

Oryginał tego wpisu dostępny jest pod adresem LogParser, UTC czy jakiś inny?

Autor: Paweł Goleń