동작원리 4 - JS(데이트 객체)

김영현·2023년 9월 21일
0

동작원리

목록 보기
5/7

Date

JavaScript Date 객체는 시간의 한 점을 플랫폼에 종속되지 않는 형태로 나타냅니다. Date 객체는 1970년 1월 1일 UTC(협정 세계시) 자정과의 시간 차이를 밀리초로 나타내는 정수 값을 담습니다.
https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Date

그렇다. Date객체는 UTC0시0분과의 시간차이를 밀리초로 환산한 것이다.
UNIX 시간은 초 단위로 환산한 것이니 헷갈리지 말자.

콘솔에 쳐보면 요래 나옴


요일, 월, 일, 년도, 시,분,초, 그리니치 천문대에서 몇시간 흘렀는지, 현지 국가
참고로 GMT라는 명칭은 UTC로 바뀌었다. 왜 업데이트 안해줌?

Date는 객체이기에 많은 메소드가 있다. 그중 재밌는 녀석이 있음.
Date.parse()는 날짜를 나타내는 문자열을 파싱해 1970년 1월 1일 00:00:00 UTC부터 시간 차이를 밀리초 단위의 숫자 값으로 반환해준다.

이렇게말이다. 근데 부연설명이 있다.

알면 알수록 재밌는 언어다.

참고로 Date.getDay같이 get...으로 시작하는 메소드는 현지시각으로 나온다.
물론 UTC기준으로 반환해주는 Date.getUTCDay도 있음.

하지만 조금 아쉽다. 강사님이 설명해주셨던 Time Zone에 관련된 기능이 없다.
이를 위해 Temporal이라는 API가 새로 개발중이다.


Temporal

Date객체의 문제점을 해결하기위해 등장한 새로운 API다. tc39에서 만드는중!(js발전 위원회)
사실 큰 프로젝트나 국제적 프로젝트를 경험한 적이 없는 나로서는 잘 와닿지 않았는데

https://maggiepint.com/2017/04/09/fixing-javascript-date-getting-started/

이곳의 글을 보고 조금은 알게됐다. 나열된 Date의 문제점을 몇가지 써보자면...

  1. Time Zone 기능이 없다.
  2. 파서가 불안정하다(MDN 문서에서도 인정하는 바...ㅋㅋ)
  3. 날짜객체가 변경이 가능하다 => 왜지?
  4. 서머타임 예측이 안된다.
  5. 날짜계산이 귀찮다 => 밀리초로 반환하기때문에 그런듯?
  6. 그레고리력이 아닌 달력 지원 안됨 => 북한, 일본, 중국, 대만, 태국 등은 그레고리력 기반으로한 수정된 달력 사용중이니...

블로그의 화자, maggie는 문제의 해결법을 제시해주었다.
date객체에 메소드를 추가해 거의 해결된것 처럼 보인다.
하지만 해결 안되는 문제가 두가지 있었음.

  1. 웹 호환성으로 인한 문제
    date객체. 즉, 날짜는 계속 수정될 여지가 거의 없다. 따라서 불변해야하는데...
    지금까지 사용된 코드들은 모두 불변하지 않은 date객체를 다뤘음.
    => 갑자기 불변 객체로 바꿔버리면 레거시 코드와의 충돌 필연.

  2. 웹 현실성

toISOString()메소드는 ISO8601을 기준으로 반환해준다.
=> 둘다 로컬타임으로 추론되어야하는데, 다르게나옴
이는 ES5시절 생략된 타임존과 값은 모두 Z 로 결정됐었기 때문.
업데이트 하려 했지만...역시나 레거시코드와의 충돌때문에 하지 못함.
현실적이구먼.

아무튼 위와같은 이유들 때문에 아예 새로운 API를 만들어내시는 중이다.
자세한 메소드들은 링크에 있으니 관심있으면 보고오자.

느낀점

많은 사람들이 사용하고있는 것을 함부로 바꾸는건 어렵다...가 아니라.
Date객체를 뭣모르고 사용하고 있었구나.
시간은 상대적, 절대적인 것이었는데 간과하고 있었다.
특히 UTC는 알고있었지만, Time Zone은 생각도 못하고 있었음.
아무튼 Tc39 프로세스 행님들 화이팅!

profile
모르는 것을 모른다고 하기

0개의 댓글