시간을 UTC로 저장하는 것이 항상 좋은 생각입니까, 아니면 현지 시간으로 저장하는 것이 더 좋은 경우입니까?

시간을 UTC로 저장하는 것이 항상 좋은 생각입니까, 아니면 현지 시간으로 저장하는 것이 더 좋은 경우입니까?

---

일반적으로 여기 와 여기에 언급 된대로 UTC로 시간을 저장하는 것이 가장 좋습니다 .

반복되는 이벤트가 있다고 가정 해 보겠습니다. 종료 시간이 항상 같은 현지 시간이라고 가정하겠습니다. 일광 절약 시간이 해당 시간대에 대해 켜져 있는지 여부에 관계없이 17:00이라고 가정하겠습니다. 또한 특정 시간대에 DST가 켜지거나 꺼질 때 시간을 수동으로 변경하지 않아도됩니다. API (즉, GetEndTimeByEvent)를 통해 다른 시스템에서 종료 시간을 요청할 때마다 항상 종료 시간을 UTC 형식으로 전송해야합니다.

접근 방식 1 : UTC로 저장 하기로 결정 하면 아래와 같이 데이터베이스 테이블에 저장할 수 있습니다.

Event      UTCEndTime
=====================
ABC         07:00:00
MNO         06:00:00
PQR         04:00:00

첫 번째 이벤트 ABC의 경우 UTC의 종료 시간은 오전 07:00이며, 2012 년 7 월 1 일에 UTC에서 현지 시간으로 표시하도록 변환하면 현지 시간으로 17:00이되고 2012 년 10 월 10 일에 변환되면 ( 시간대에 DST가 ON 인 날짜) 오후 6 시가되며 이는 정확한 종료 시간이 아닙니다.

내가 생각할 수있는 한 가지 가능한 방법은 추가 열에 DST 시간을 저장하고 시간대에 DST가 켜져있을 때 해당 시간을 사용하는 것입니다.

접근 방식 2 : 그러나 이벤트 ABC의 경우와 같이 아래와 같이 현지 시간 으로 저장되면 UTC에서 현지 시간으로의 변환이 없기 때문에 모든 날짜에 항상 17:00이됩니다.

Event      LocalEndTime
=======================
ABC         17:00:00
MNO         16:00:00
PQR         14:00:00

그리고 애플리케이션 계층은 (API GetEndTimeByEvent)를 통해 다른 시스템으로 전송하기 위해 현지 시간을 UTC 시간으로 변환합니다.

이 경우에도 시간을 UTC로 저장하는 것이 좋은 생각입니까? 그렇다면 일정한 현지 시간을 얻는 방법은 무엇입니까?

관련 질문 : UTC가 아닌 시간을 저장해야하는 합당한 이유가 있습니까?

---

이 질문에 답하려면 UTC를 사용하여 타임 스탬프를 저장하는 이점에 대해 생각해야한다고 생각합니다.

나는 개인적으로 그것의 주된 이점은 시간이 항상 (대부분) 일관성이 보장된다는 것 입니다. 즉, 시간대가 변경되거나 DST가 적용될 때마다 시간을 앞뒤로 이동할 수 없습니다. 이것은 특히 파일 시스템, 로그 등에 유용합니다. 그러나 응용 프로그램에 필요 합니까?

두 가지를 생각해보십시오. 첫째, DST 클럭 시프트 시간에 대해. 이벤트가 오전 2시에서 3시 사이에 발생할 가능성이 있습니까 (시계 이동이 끝난 날)? 그러면 어떻게됩니까?

둘째, 애플리케이션이 실제 시간대 변경의 대상이됩니까? 즉, 런던에서 바르샤바로 비행하고 컴퓨터 시간대를 적절하게 변경 하시겠습니까? 이 경우 어떻게해야합니까?

두 질문에 모두 아니오 라고 답했다면 현지 시간이 더 좋습니다. 응용 프로그램이 더 간단 해집니다. 하지만 적어도 한 번 예라고 답했다 면 더 생각해야한다고 생각합니다.

---

그리고 그것은 데이터베이스에 관한 것입니다. 다른 하나는 응용 프로그램에서 내부적으로 사용하는 시간 형식이며 해당 시간으로 실제로 수행 할 작업에 따라 달라집니다.

API를 통해 시간을 노출한다고 언급하셨습니다. 애플리케이션이 모든 요청에 ​​대해 데이터베이스를 쿼리합니까? 시간을 내부적으로 UTC로 저장하는 경우이를 수행하거나 DST / 시간대 변경시 캐시 된 시간이 조정 / 정리되는지 확인해야합니다.

시간 자체로 무엇을할까요? 이벤트를 인쇄 하는 것처럼 8 시간 내에 발생 하거나 그 시간 동안 자체적으로 중단됩니까? 그렇다면 UTC가 더 나을 것입니다. 물론 앞서 언급 한 모든 문제를 생각해야합니다.

---

나는 이것을 이렇게 생각하고 싶다.

컴퓨터는 인간이 이해할 수있는 표현으로 시간을 신경 쓰지 않습니다. 표준 시간대, 날짜 및 시간 문자열 형식 또는 그 어떤 것도 신경 쓰지 않습니다. 인간 만이 시간을 해석하고 표현하는 방법에 관심이 있습니다.

데이터베이스에서 시간을 숫자로 저장하도록하십시오. UNIX epoch (1970-01-01 이후 경과 된 초 수) 또는 UTC 타임 스탬프 (시간대 또는 일광 절약 시간 정보 없음) 중 하나입니다. 시간을 인간이 이해할 수있는 방식으로 표현하는 데에만 관심을 두십시오. 즉, 응용 프로그램 논리,보고 시스템, 콘솔 응용 프로그램 또는 기타 사람이 데이터를 볼 수있는 모든 위치에서 의미합니다.

---

다음은 진정한 멀티 테넌트 글로벌 SaaS 제품에는 적용되지 않으므로이 의견은 단순한 "기간 업무"앱 개발자를 대상으로합니다.

UTC로 저장하는 것은 좋지만 이렇게하면 고통을주는 한 가지 요구 사항이 있습니다. "하루에 발생하는 X의 수를 보여주는 보고서를 작성해 주시겠습니까?"

날짜를 UTC로 저장하는 경우이 요구 사항은 고통을 유발합니다. 애플리케이션 서버와보고에 시간대 조정 코드를 작성해야합니다. 날짜 기준이 포함 된 데이터에 대해 수행하는 모든 임시 쿼리는이를 고려해야합니다.

신청이 다음 기준을 충족하는 경우 :

1. 각 인스턴스는 단일 시간대를 기반으로합니다.
2. 시간대 전환은 일반적으로 근무 시간 외에 이루어 지거나 누락 된 시간 정도가 중요 할 정도로 사물의 "지속 시간"에 대해서는 신경 쓰지 않습니다.

서버 시간대 구성 문제 (예 : .net 세계의 Noda.Time)에서 격리하는 라이브러리를 사용하면서 datetime을 로컬 날짜 시간으로 저장하는 것이 좋습니다.

---

시스템 간 메시지가 ISO 8601을 사용하고 데이터베이스가 원본 로컬 시간 + 오프셋을 저장하고 ( datetimeoffsetMSSQL 또는 ISODateMongo에서 ISO 8601이 캡처하는 것과 같이) DateTimeOffset.NET 또는 OffsetDateTimeJava 또는 이와 동등한 버전 에서만 사용하는 경우 코드를 입력하면 변환이 전혀 필요하지 않습니다. 당신은 그것을 저장합니다. 모든 비교 기능이 작동합니다.

지속성에서 UTC로 변환하면 사용자의 관점에서 오프셋을 잃은 것입니다. 사용자가 10 년 전에 문서에 서명 한 시점을 표시하는 것은 이제 어려운 문제입니다. UTC에서 작업하는 것은 해당 지역에서 당시 적용되었던 DST 규칙을 찾는 것을 의미합니다. 악몽.

I believe the reason we are all so used to converting to UTC for persistence is because we never used to have the right datastructures/data-types to allow us to do the right thing.

---

I would just store the Time component only without any Zone. Whenever the API has to serve it, add the correct date and convert that as local time to UTC for that date.

Database = 17:00 (use a timestamp without date, hours as byte, minutes as byte, string)

Retrieve = Date where we want the event + Database 17:00 => Convert this from local to UTC

This way you will always serve the correct time in UTC.

---

You're actually not storing a specific point in time as most time APIs assume. Use intervals if your database supports it (PostgreSQL does) or store it as an integer representing the number of seconds (minutes/hours) since midnight or corresponding beginning of the schedule (Monday, the first of the month, etc). In either case, you've dropped a lot of the headaches of worrying about how "Time" is handled between systems, and added only a very minor headache of converting seconds to time of day in your view.

ReferenceURL : https://stackoverflow.com/questions/11537106/is-it-always-a-good-idea-to-store-time-in-utc-or-is-this-the-case-where-storing