이 글을 쓰는 이유는 예약 관련 서비스를 할 때 어떤 방법으로 고려해야 하는지 고민할 걸 남기기 위해서이다.
기본적으로 Date, DateFormatter는 어떤 것인지 알고 있다고 생각하고 쓸려고 한다.
결론부터 말하자면 예약자에게 보여주고 서버에 통신할 때는 DateFormatter에서 TimeZone.current를 이용하고 서버에선 그대로 저장을 한다. 우리는 서버에서 받은 것을 TimeZone(abbreviation: "UTC")으로 바꿔서 보여주면 된다.
이게 무슨 소리냐면..
https://en.wikipedia.org/wiki/List_of_time_zone_abbreviations
위에 Time zone abbreviation 정보로 설명을 해보자.
기본적으로 Date를 다를 때는 UTC를 기준으로 데이터를 다룬다. 그 데이터에서 현재 locale을 기준으로 보여줄 때 한국은 UTC+09이다
그러니깐 2019-03-20T 04:31:28.000Z 이 데이터의 UTC 기준은 2019년 03월 20일 오전 4(04) 시 31분 28초이다. 하지만 timeZone을 "KST" korea standard time으로 바꾸면 2019년 03월 20일 오후 1(13) 시 31분 28초로 바꿔서 보여준다. 유저는 화면상에서 당연히 2019년 03월 30일 오후 3시 31분에 예약을 했다고 생각할 것이다.
우리는 Request를 2019-03-20T 13:31:28.000Z로 보낼 것이고 서버는 그 값을 그대로 저장할 것이다.
그리고 우리가 Response로 받은 예약시간 데이터는 2019-03-20T 13:31:28.000Z로 받을 것이다.
자 보자.
서버에서 2019-03-20T 13:31:28.000Z로 데이터를 보내줬기 때문에 우리는 유저에게 그 값 그대로 보여줘야 한다.
그런데 여기서 DateFormatter를 기본 current로 해 버린다면 저 시간은 또 +9를 해주게 될 것이고 유저는 2019년 03월 30일 오후 1(13)시 31분 28초 이 아닌 2019년 03월 30일 오후 10(22) 시 31분 28초로보여주게 되어 혼란스럽게 될 것이다.
요약
예약 중
유저 예약 시간 : 2019년 03월 20일 오후 1시 30분
예약 후 잘못된 timezone 설정
유저 예약 시간 : 2019년 03월 20일 오후 10시 30분
이렇기 때문에 서버에 예약 시간을 보낼 때는 현재 타임존 기준으로 보내주고
서버에서 데이터를 받으면 UTC 기준으로 DateFormatter의 timeZone을 바꿔주어 보여 줘야 한다.
그렇다면 왜 도대체 uct 기준으로 통신을 주고받지 않고 보낼 때는 현재 로컬, 받을 때는 utc 기준으로 보여줬느냐...?
일반적으로 데이터를 주고받을 때는 utc 기준으로 주고받으면 상관이 없을 것 같다.
하지만 예약은 조금 다르다.
가정을 하면 나는 현재 한국에 있고 2019년 12월 25일 오후 1시 30분에 영국에 있는 국밥집에 식당 예약을 한다고 치자.
서버에는 영국시간 2019년 12월 25일 오후 1시 30분에 저장을 해야 한다.
한국은 uct +9이고 영국은 utc +0이다
잘 생각해보자. 서버에 주고받을 때랑 내가 유저의 하면에 보여줄 때랑 다르다는 것을..
현재 나는 한국이다.
날짜를 선택한다. 2019년 12월 25일 오후 1시 30분(영국 국밥집)
예약 후에도 현재 나는 한국이다.
위에 적어 놓은 것처럼 utc 그대로 날짜를 보여준다. (2019년 12월 25일 오후 1시 30분)
나는 현재 한국이고 화면에 보이는 예약 확인 날짜 또한 2019년 12월 25일 오후 1시 30분이다.
나는 24일에 영국에 도착을 했다.
앱을 켜고 예약 날짜를 다시 확인해보자. 2019년 12월 25일 오후 1시 30분로 잘 보인다. 내가 처음에 보낸 그 날짜가 절댓값이 되었다. 아주 잘 됐다.
utc 기준으로만 통신을 해보자.
나는 현재 한국이다.
날짜를 선택한다. 2019년 12월 25일 오후 1시 30분(영국 국밥집) utc 기준 2019-03-20T 04:31:28.000Z 에 예약
예약 후에도 현재 나는 한국이다.
utc 그대로 보여줄 경우 오전 4시 그러면 현재 지역 기준으로 보여준다면 오후 1시로 보여줄 것이다.
나는 24일에 영국에 도착을 했다.
앱을 켜고 날짜를 다시 확인해본다. 응? utc, 현재 로컬 기준으로 오전 4시로 예약이 되어 있다. 왓더ㅃ
utc 자체는 절댓값이지만.. 우리는 나라의 지역 기준에 따라 날짜가 달라지기 때문에.. utc 기반으로 예약을 하는 건 옳지 않다.
다른 방법이 있는지는 모르겠다.
하지만 하나 확실한 건 나의 예약시간은 변수에 따라 변하는 게 아니라 절대 값이어야 한다는 것이다.
친구야 나 다음 주에 화요일 미국에 가는데 오후 1시에 공항에 도착하니깐 그렇게 알고 있어..
라고 한다면 말하는 사람과 그걸 듣는 사람 당연히 미국 시간 기준 오후 1시가 절댓값이다.
그렇기 때문에 서버 DB에는 그 절대적인 시간을 저장을 하고 우리가 보여줄 때는 절대적인 그 시간을 지역의 TimeZone이 아닌 UTC 기준으로 그대로 보여주면 된다.
물론 제일 좋은 건 서버가 그냥 년 월 일 그대로 우리한테 주면 되지만.... 아 그러면 이 글을 쓸 이유가 없었네.. 서버가 조금 더 해줬으면..
우리는 그렇게 하지 않고 있기 때문에..서버가 다 해줘라!
'개발 블로그 > 아이폰개발' 카테고리의 다른 글
[iOS 앱 내 구입] iOS 앱 내 결제 시스템 구현편 (0) | 2019.12.13 |
---|---|
[iOS 앱 내 구입] iOS 앱 내 결제 시스템을 구현하면서 필수 고려할 사항 정리 (2) | 2019.12.04 |
[iOS] App Lifecycle( 앱 생명주기) (0) | 2019.11.27 |
[iOS DateFormatter Locale] Date->String Locale identifier 사용표 (0) | 2019.11.21 |
[swift Date, DateFormatter] Date->String , String->Date 일때 locale(identifier), TimeZone(abbreviation) 관계 (0) | 2019.11.21 |
[Objectvie-c 의 블록] objectvie c 블록[block] 2장 메모리 영역 (0) | 2019.11.08 |
[Objectvie-c 의 블록] objectvie c 블록[block] 1장. (0) | 2019.11.08 |
frame 과 bounds 차이라면..? Swift, Xcode, iOS 개발 (0) | 2019.10.30 |
델리게이트(Delegate) 위임 패턴이란? (0) | 2019.10.23 |
ARC, 순환참조와 소유권 지시어 (iOS, xcode) (0) | 2019.10.22 |
댓글