답변

SQL에는 날짜 및 간격을 처리하기 위한 다양한 함수가 있습니다: DATEDIFF, DATEADD (T-SQL), INTERVAL 유형 작업 (PostgreSQL), 다양한 시간대에 대한 변환 기능 (AT TIME ZONE). 날짜를 올바르게 처리하기 위해서는 시간대가 포함된 데이터 유형 (TIMESTAMP WITH TIME ZONE, timestamptz)을 사용하는 것이 중요하며, 단순히 DATE 또는 DATETIME을 사용하는 것은 특히 글로벌 서비스에서는 피해야 합니다.

다양한 DBMS에서 구문 및 작업의 특성이 다릅니다:

SQL Server: DATEDIFF, DATEADD, FORMAT 지원, 그러나 완전한 INTERVAL은 없음. 시간대는 명시적으로 관리됨.
PostgreSQL: INTERVAL 지원, 여러 함수 (+/- INTERVAL), 시간대 직접 관리 가능.

오류는 종종 UTC/로컬 시간을 일관되지 않게 저장하거나 차이를 고려하지 않는 연산의 혼합으로 인해 발생합니다.

시간 차이 계산 예제 (PostgreSQL)

SELECT
  EXTRACT(EPOCH FROM (event_end AT TIME ZONE 'UTC' - event_start AT TIME ZONE 'UTC')) / 3600 AS hours
FROM events

의도된 질문

DATEDIFF에서 날짜 차이가 음수일 수 있으며, 날짜의 순서는 무엇을 의미하나요?

답변: 네, DATEDIFF (DATEDIFF(day, d1, d2))는 d2 < d1일 경우 음수를 반환합니다. 매개변수의 순서를 헷갈리지 않는 것이 중요합니다: 첫째는 측정 단위, 둘째는 시작 날짜, 셋째는 종료 날짜입니다.

예제:

SELECT DATEDIFF(day, '2024-05-01', '2024-04-25') -- -6을 반환함

실제 오류 예제

이야기

글로벌 사용자들과의 프로젝트에서 보고서는 각 지역 서버의 로컬 시간을 기준으로 작성되었습니다. 결과적으로 날짜가 어긋나고 다른 시간대의 사용자에게는 '구멍'이 발생하였습니다. 이를 UTC로 모든 시간 데이터를 변환하고 표시를 위해서만 재계산함으로써 수정하였습니다.

이야기

DATEDIFF를 통해 구독 기간을 계산할 때 날짜 순서를 잘못 지정하여 일부 사용자가 고의로 '슈퍼 사용자'로 잘못 인정되었습니다. 날짜 순서를 확인하는 절차를 도입하여 수정하였습니다.

이야기

개발자가 시간대 고려 없이 DATETIME를 저장했으며, PostgreSQL로 마이그레이션할 때 값이 UTC로 해석되었습니다. 원래 GMT+3였기 때문에 이벤트가 보고서에서 3시간 뒤로 이동했습니다. 결론: 항상 시간대를 고려하여 날짜를 저장하고 변환해야 합니다!