▲

new Date("wtf") - JavaScript의 Date 클래스에 대해 얼마나 잘 아는가?

 (jsdate.wtf)
1P by GN⁺ 18시간전 | ★ favorite | 댓글 1개
  • 본 퀴즈는 JavaScript의 Date 클래스가 다양한 입력 상황에서 어떤 식으로 동작하는지에 초점을 맞춤
  • 사용자가 예상하지 못하는 입력값(예: "wtf" 등)이 들어올 때 Date 클래스가 반환하는 결과, 예외 여부, 내부 처리방식 등 실험 내용 포함
  • 이 퀴즈를 통해 JavaScript Date의 예외적 순간, 파싱 전략, 표준 미준수 등 예상 외의 동작 패턴을 쉽게 파악할 수 있음
  • JavaScript 개발자 및 테스트 담당자가 실제 프로그램에서 발생할 수 있는 날짜 처리 오류와 불확실성을 줄이기 위한 이해도 증진 목적
▲
GN⁺ 18시간전  [-]
Hacker News 의견
  • 내 firefox JS 콘솔에서는 이 퀴즈와는 다른 답이 나옴
  • JavaScript를 놀리지는 말아줬으면 함. 옛날에도 사람들이 그러다가 Node가 나와서 이젠 온 세상에 퍼진 상황임
    • TypeScript는 아마도 돈을 받고 쓸 수 있는 언어 중 최고의 선택이라고 생각함
    • 거의 10년간 사람들이 undefined behaviour를 정말 기술의 무의미함에 대한 결정적 증거처럼 여기던 WAT 밈이 생각남. 사실은 단순히 사람들이 기술이라는 개념을 오해했던 것임. 벽돌로 물을 담을 수 없는 게 웃긴 일은 아닌데, 이상하게도 모두가 JavaScript가 모든 ~실수~를 전부 에러로 잡거나 스스로 고쳐줄 거라고 기대했었음. 좋은 목표이긴 하지만, 그게 불가능하면 자랑스럽게 여기라는 것도 좀 이상했던 시각임. 이런 분위기가 너무 오래 이어진 경험임
  • 재밌는 퀴즈라고 생각함. 깜짝 놀랄 만한 동작도 많음. 하지만 실제로는 대체로 별로 중요하지 않다고 느낌. <br>실제 상황에서 본인이 지역 시간이 정말 필요한지 고민해보고, instant 단위로 쓰는 게 적합한지 먼저 생각했으면 함. UTC ISO 8601 문자열이나 Unix timestamp를 쓰면 복잡성의 대부분이 사라지거나, 최소한 소프트웨어의 일부에서만 신경 쓰면 됨. 물론 항상 그런 건 아님 (한 번은 사용자의 휴식 시간이 1~5시 두 구간을 포함해야 했는데, DST 경계에서 정말 고역이었음). 그래도 대부분의 경우에 신경 쓰는 영역을 최소화하는 방법을 찾는 게 가능하다고 경험함. <br>아무 검증도 안 한 사용자 입력을 date parser에 그대로 넘기면 그 사용법이 잘못된 것임
    • 사용자 입력을 올바른 형식으로 바꾸는 방법이 바로 파싱 이기 때문에, 언어에서 제공하는 date parser 에 전달하는 게 합리적이라고 생각함. 이게 잘 안 된다는 사실이 JavaScript 프로그래머들에겐 별로 놀랍지 않다고 생각함
    • "아무 검증도 안 한 사용자 입력을 date parser에 넘기면 안 됨"이라는 말에 완전히 동의함. 근데 제대로 된 API와 그렇지 않은 API의 차이는, 제대로 된 API는 이상이 있으면 바로 실패하고 "네가 뭘 잘못 쓰고 있다"고 알려 주는 것임. 일단 뭔가 조금이라도 이상하면 제대로 실패해야지, 이상한 데이터를 어떻게든 처리하려고 해선 안 됨. 많은 JS API는 어떤 일이 있어도 동작하도록 설계된 게 문제라고 생각함. NaN이 나오는 것도 원하지 않고, 문자열을 어정쩡하게 변환하는 것도 원하지 않음
    • "UTC ISO 8601 문자열이나 Unix timestamp만 쓰면 된다"는 말을 할 때마다, 그런 사람들은 날짜를 되게 한정된 방식으로만 다뤄봤다는 생각이 듦. <br>미래 날짜에 그런 전략을 써보면 어떤지 생각해보면 됨. 예를 들어 "저녁 7시에 만나자"라는 약속은 썸머타임이 변경되거나 시간이 바뀌어도 7시에 만나는 게 중요함. 이런 일은 실제로 자주 일어남. <br>사실 더 미묘한 문제임. 어떤 앱에서는 반드시 시간대의 맥락이 필요함. 예를 들어 레스토랑 예약을 보여주는 서비스라면, 사용자의 현지 시간이 아니라 레스토랑의 현지 시간대로 보여야 함. 예약 시간은 "거기" 시간이 중요하지, 내가 지금 어디 있느냐가 중요하지 않음. <br>즉 GMT/UTC가 모든 날짜 문제의 만병통치약은 아님. <br>과거 날짜라면 괜찮은 해결책이긴 한데, 이럴 때도 사용자의 현지 시간이나 이벤트 발생 당시 시간대를 따로 저장하는 게 도움이 될 때가 많음
    • DST 오프셋을 명시적으로 지정할 수 있는 옵션을 주는 것도 좋은 방법이라고 생각함. 상황에 따라 유용한 경우가 있음. Excel이 CSV 사용할 때 포맷을 스스로 추론하지 않는 것도 항상 혼란스러웠음
    • 이 내용에 동의함. 초보자라면 쉽게 빠질 수 있는 함정인데, 이번 퀴즈로 많은 사람들이 한 번 더 생각해보는 계기가 되었으면 좋겠음
  • 놀라운 부분이 굉장히 많음! 대체적인 흐름은 파서가 주어진 입력을 어떻게든 날짜로 해석하려고 지나치게 애쓰는 모습이라고 생각함. 그 해석이 매우 원칙이 없거나, 심지어 인간 사용자가 봐도 동의하지 않을 만큼 이상해도 강제로 의미를 부여하는 것 같음. 실제 해석하지 못하는 상황에서도 에러 신호를 줄 방법이 있는데, 그런 걸 적극적으로 활용하지 않는 느낌임. 물론 어쩌면 별난 케이스들이 현실의 이상한 사용 사례에서 온 것일 수도 있으리라고 생각함
    • 이런 동작은 예측 자체가 불가능하다고 느낌. 그냥 랜덤에 가까운 잡음임. 32-49번 문자열까지는 2000년대로 나온 반면, 50번 이후는 1900년대로 해석됨. <br>이럴 땐 그냥 전부 갈아엎고 다시 만드는 게 맞다고 생각함
    • 무조건 유효한 결과를 내려고 코드를 짜고 싶은 욕구를 공감함. <br>근데 대부분은 그런 충동을 억제할 수 있었음. 근데 이걸 설계한 사람들은 왜 억제하지 못했는지 궁금함
    • 이 현상은 경력 몇 년 차 개발자들에게서 흔히 나타나는 문제임. <br>주니어 개발자는 에러만 보고 겨우 동작하게 하기 바쁨. <br>미드레벨 개발자는 "무조건 에러를 줄이자" 마인드에 집착해서 파서가 과도하게 많이 가정함. 그래서 Date 클래스 같은 현상이 나옴. <br>시니어 개발자는 이런 에러의 위험성을 뼈저리게 알고, 일관되고 robust하게 디자인해서 잘못된 입력은 바로 에러내게 작성함
  • 17/28점 획득했음. 정말... 저주받은 문제들이라고 생각함! 아마 이제 이 Temporal stuff도 한 번 살펴봐야 할 시점인 것 같음
  • 10/28점 맞음. 그리 나쁘진 않은데, 구현마다 결과가 다를 수 있다고 생각함: https://developer.mozilla.org/en-US/docs/…
    • 17/28이 나왔는데 뿌듯해야 할지 창피해야 할지 모르겠음. 도대체 왜 이런 걸 알고 있는지 나도 궁금함. 내 아들은 JS Date 경험이 하나도 없는데 그냥 이전 답을 보고 유추해서 11/28 받았음. 타입 변환이 뭔지 내가 설명해줬음. 그러다 보니 내가 아들에게 IT 진로를 방해한 거 아닐까 하는 생각이 듦
    • 정말로 구현마다 다름. 내가 퀴즈 맨 앞에다 특정 Node 버전과 특정 타임존에서 검증했다고 일부러 써둠, 둘 다 결과에 중요한 영향 있음
    • 퀴즈 시작 부분에 저자가 자기 노트북의 정확한 시간대를 명시해둔 걸 봤음. 틀린 문제 중 하나가 그걸 신경 안 써서 그런 것 같음. 분명히 타당한 설명이라고 생각함. 시작 전부터 그런 게 핵심이 될 것 같단 걸 알아챘어야 한다는 생각이 듦
  • JS에서 날짜는 iso 문자열을 사용하는데, 워낙 위험한 함정이 많기 때문임. (심지어 퀴즈 초반 몇 개 문제만 봐도 알 수 있음) Moment 등 인기 대안 라이브러리들도 여러 면에서 똑같이 문제가 심각함. "date", "time", "datetime"이란 개념을 뒤섞어서 더 큰 혼란을 초래함. "time"과 "date"라는 구분은 없어야 한다는 식의 설명도 들었는데, 내 경험과는 완전히 맞지 않는 생각임
    • Moment, Luxon, Day.js 같은 유명한 라이브러리들이 별개의 시간 개념(절대시간, 시민시간 등)을 하나의 객체로 처리하는 과오가 있음. 절대시간이랑 시민시간이 그냥 같은 거 아닌가? 무리하게 하나로 묶으려 함
  • 내가 얻은 점수는... 11월 28일 2000년...인 것 같음
    • 이거 보고 한참 웃었음
  • 한 가지 궁금한 점은 어떻게 이런 일이 벌어졌을까임. 정말 초짜들이 모여서 급하게 만들어낸 일관성도 없고, 서로 섞을 수조차 없는 온갖 휴리스틱이 난무하는 결과처럼 보임. 근데 실제로는 초보자들 작품이 아니었을 텐데, 뭐가 이런 상황을 만들었는지 궁금함
    • 다른 댓글에서도 언급됐는데, Brendan Eich가 트위터에서 (링크) 직접 언급하기를 Java의 Date 클래스 동작을 그냥 복사한 거라고 밝힘. 내겐 이런 역사적 맥락이 신기함
    • 사실상 대부분의 문제가 날짜와 전혀 상관없는 이상한 문자열을 억지로 파싱할 때 생긴 것임. 거의 edge case임. 물론 edge case에서 더 일관성 있게 에러만 내주는 게 좋겠지만, 사용자가 입력한 아무 문자열이나 Date.parse()로 바로 넣는 게 아니라면 그리 문제 되진 않음. 실제로는 전문 날짜 라이브러리를 쓰게 됨. Date의 괜찮은 부분조차 그리 훌륭하지 않으니까
    • 언어에서 operator overriding이 가능하거나 정적 타입이 없으면, 하나의 메소드가 10가지 서로 다른 용도에 맞춰 동작해야 하는 일이 종종 일어남. Java나 C++도 이런 일관성 없는 API가 꽤 있음(그래도 JS만큼 심각하진 않음)
  • JS 퀴즈는 웃으려고 클릭하는 재미가 있음. 10년 넘게 JS 써왔는데, regex로 검증하지 않은 문자열을 Date로 파싱해본 적은 없음
    • 그러면 문제를 두 개 만들게 됨
    • 비슷한 공감임. 10년 동안 보안 관련 JS 코드를 짜봤음. 표준이 크게 업데이트 될 무렵이었음. 우리 시스템은 브라우저마다 일관되게, 예측 가능하게 동작하는 정말 작은 부분만 썼음. 표준이 바뀐 뒤에도 array.filter랑 structuredcopy만 추가하고, 나머지는 실질적 이득도 없고 공격 표면만 늘어나서 다 무시했음. <br>그리고 TypeScript가 나왔는데, JS 역사상 가장 큰 기회 상실이었다고 생각함. <br>지금도 JS에서 제대로 코딩한다는 건, 사실상 언어의 1%만 조심스럽게 쓰는 것임. 그것조차 신중하게 써야 함
답변달기