DateTime.Now vs DateTime.UtcNow.ToLocalTime

안녕하세요, 저는 비전 검사쪽을 하고있습니다.
검사기를 담당하다 보니까 검사를 시작한 시간, 이미지를 생성한 시간 등등 기타 등등에서 DateTime.Now를 자주 사용하고 있는데요, 최근 DateTime.Now와 UtcNow가 속도 차이가 난다고 알게 되어 이것저것 테스트 중에 있습니다.

검색해보니 내부 구현이 다르기 때문으로 알게됐고
실제로 테스트해보니 아래처럼 Utc 시간이 훨씬 빠른 속도를 보여주고 있었습니다.

아래 블로그에서 DateTime.UtcNow.ToLocalTime()을 사용하면 Utc시간을 다시 LocalTime으로 변환해준다고 하고 실제로 속도를 측정해보니 Utc보다는 아니지만 Now보다는 훨씬 빠른 속도를 내고 있었습니다.

image

앞으로 개발되는거에 DateTime.UtcNow.ToLocalTime을 적용하고 싶은데.
혹시 사용해보신 개발자분이 계신지. 다른분들은 어떻게 사용하고 계신지 궁금합니다.
작은 경험이여도 좋으니 답변해주시면 감사하겠습니다 ㅎㅎ

3 Likes

링크된 글에서 설명했다시피, UTC는, 속도 측면 보다는, 복수의 타임 존 컨텍스트에서 올바른 시간 비교를 위한 것입니다.

속도가 빠르다는 이유로, DateTime.UtcNow.ToLocalTime()을 호출하면, 이는 DateTime.Now와 같아, 타임 존 사이에 시간 비교가 안됩니다.

예를 들면, 아침 10시에 DateTime.Now 값을 저장한다고 할 때, 서울 검사기가 저장한 값과 미국 동부에 있는 검사기가 저장한 값은 같습니다.

그러나, 두 검사기의 시간대가 다르기에 저장된 결과의 직접 비교는 올바른 결과를 나타내지 않습니다.

링크된 문서에서는 utc와 로컬 타임이 선택의 문제인 듯한 뉘앙스가 있지만, 일반적으로, DB에 저장할 시간은 UTC time으로 하는 게 권고 사항입니다.
(Display 나 연산을 위해서, 로컬 타임으로 변환합니다.)

물론 DB에 이미 로컬 타임으로 저장했으면 이를 손대면 안되겠죠.

1 Like

우선 좋은 답변 감사합니다 ㅎㅎ

특이사항을 제가 미리 말했어야 했는데, 죄송합니다

고객사에 PC를 납품할때 시스템 시간을 서버로 동기화를 시킵니다.
그렇기 때문에 UtcNow를 사용하지 않고 Now로만 작성하고 있습니다.

이처럼 타임존 비교가 필요없는 환경이라면 속도만의 이점으로 사용할만한 가치가 있지 않을까 생각해봤습니다

아침에 다시 테스트해보니 우선 어제 DateTime.Now로 본 시간 자체가 14ms나 나온게 좀 이상하다고 판단되어 다른 테스트를 더 해봐야 할 거같습니다. ㅎㅎ

추가답변은 안해주셔도 괜찮을거 같습니다. 소중한 답변 주셔서 감사합니다.

1 Like