오늘도 실수 얘기 좀 해보자. 날짜랑 시간 다루는 건 진짜 지뢰밭 걷는 거랑 똑같아. 한 발 잘못 디디면 바로 터진다니까.
데이터 타입 고를 때 실수
여기서부터 이미 삐끗하는 경우가 많아. 데이터 타입 잘못 고르면 날짜랑 시간 다루려고 했던 노력 다 날아갈 수도 있어.
상황 1: DATE 대신 TIMESTAMP 안 쓴 경우
이벤트 기록할 때 날짜뿐만 아니라 시간까지 중요한데, DATE만 쓰면 중요한 정보 다 날아갈 수 있어.
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
order_date DATE -- 날짜만 저장
);
이렇게 테이블 만들면, 주문이 아침에 들어왔는지 저녁에 들어왔는지 알 방법이 없어. 굳이 커피 마시면서 예쁜 타임스탬프 구경할 기회를 왜 버려?
상황 2: 타임존 신경 안 쓴 경우
앱이 해외 유저들도 쓴다면, TIMESTAMP만 저장하고 타임존 신경 안 쓰면 데이터가 "집 없는" 상태가 돼버려. TIMESTAMPTZ 쓰면 이런 문제 바로 해결!
CREATE TABLE events (
event_time TIMESTAMP -- 타임존 없음
);
아무도 뉴욕에서 저녁 행사랑 도쿄에서 아침 행사 헷갈리고 싶진 않잖아. TIMESTAMPTZ 꼭 써!
함수 쓸 때 실수
상황 1: TO_CHAR()에서 포맷 잘못 쓴 경우
포맷 잘못 쓰면 바로 문제 생긴다. 예를 들어:
SELECT TO_CHAR(NOW(), 'YYYY-DD-MM'); -- 어, 월이랑 일이 바뀜
원래 년-월-일로 나와야 하는데, 년-일-월로 나와버렸지. 이러면 유저들한테 웃긴(근데 별로 안 좋은) 상황 생길 수 있어. 항상 포맷 제대로 확인해.
상황 2: TO_DATE() 쓸 때 실수
반대로, 문자열을 날짜로 바꿀 때 포맷이 안 맞으면 PostgreSQL이 에러 뿜어.
SELECT TO_DATE('10/31/2023', 'YYYY-MM-DD'); -- 에러! 포맷이 안 맞음.
문자열 포맷이랑 네가 지정한 포맷이 딱 맞아야 해. 예를 들어:
SELECT TO_DATE('2023-10-31', 'YYYY-MM-DD'); -- 이건 제대로 됨.
시간 간격(Interval) 관련 실수
상황 1: 암시적 타입 변환 실수
가끔 타입 변환 신경 안 쓰고 그냥 쓰면 이런 일이 생겨:
SELECT NOW() + '1'; -- 에러! '1'이 뭔지 모름.
PostgreSQL은 네가 하루 더하고 싶다는 걸 몰라. 제대로 하려면 이렇게:
SELECT NOW() + INTERVAL '1 day';
상황 2: Interval 빼기 헷갈림
Interval 더하거나 뺄 때도 조심해야 해:
SELECT NOW() - INTERVAL '-1 day'; -- 이건 하루 더해지는 거야!
마이너스 두 번 쓰면 반대로 동작해버려. 이런 건 피하는 게 좋아.
반올림, 자르기 관련 실수
상황 1: DATE_TRUNC()로 잘못 자른 경우
DATE_TRUNC()로 데이터 그룹핑할 때, 네가 원하는 레벨 맞게 잘랐는지 꼭 확인해. 예를 들어:
SELECT DATE_TRUNC('hour', NOW()); -- 시간 단위로 자름
SELECT DATE_TRUNC('minute', NOW()); -- 분 단위로 자름
원하는 결과랑 다르게 나오면, 레벨 잘못 고른 걸 수도 있어.
상황 2: DATE_TRUNC() 쓸 때 타임존 까먹은 경우
여러 타임존에서 시간 다루면, 결과가 예상 밖일 수 있어:
SELECT DATE_TRUNC('day', NOW() AT TIME ZONE 'UTC');
타임존 제대로 지정했는지 꼭 확인해. 안 그러면 진짜 시간 속에서 길 잃는다(진짜로).
Unix 시간: 잃어버린 초들
Unix 시간(EPOCH)은 편하긴 한데, 진짜 헷갈릴 수 있어. 제일 흔한 실수는 초랑 밀리초 헷갈리는 거야.
SELECT TO_TIMESTAMP(1680000000); -- 이건 맞아(초 단위).
SELECT TO_TIMESTAMP(1680000000000); -- 이건 에러! 0이 너무 많아.
네 타임스탬프가 뭘로 측정되는지 꼭 확인해서, 쓸데없는 초 백만 개 저장하지 마.
타임존 관련 실수
상황 1: 헷갈리는 타임존
여러 타임존 유저랑 작업하면, 데이터가 섞일 수 있어. 예를 들어:
SELECT TIMESTAMP '2023-10-01 10:00:00' AT TIME ZONE 'UTC';
데이터가 어느 타임존에 있는지 확실히 알고 있어야 해.
상황 2: 타임존 중복 적용
날짜랑 시간 저장할 때 타임존 한 번 적용하고, 또 한 번 적용하면 진짜 안 좋아:
SELECT TIMESTAMP '2023-10-01 10:00:00 UTC' AT TIME ZONE 'UTC'; -- 이렇게 하지 마!
이러면 계산이 완전 꼬일 수 있어.
실수 안 하려면 이렇게 해!
적절한 데이터 타입 고르기. 해외 시간 데이터 다룬다면 TIMESTAMPTZ 써. 날짜만 필요하면 DATE로 충분해.
쿼리 꼭 테스트하기. 결과가 네가 기대한 거랑 맞는지 항상 확인해. 특히 Interval, 포맷, 반올림 쓸 때는 더더욱!
시간 데이터는 UTC로 저장하기. 이게 타임존 헷갈림 피하는 제일 좋은 방법이야.
포맷 꼼꼼히 확인하기. TO_CHAR()랑 TO_DATE() 포맷이 네 데이터랑 맞는지 꼭 체크해.
함수 쓸 때 조심하기. PostgreSQL 시간 함수 공식 문서 꼼꼼히 읽어보고, 이상한 결과 안 나오게 해.
시간 데이터 다루는 거 쉽진 않지만, 꼼꼼하게 하면 진짜 부드럽게 처리할 수 있어. 날짜랑 시간은 네 앱에서 진짜 중요한 부분이니까, 월요일 아침 알람 안 맞춘 것처럼 까먹지 마!
GO TO FULL VERSION