Hacker News 의견

• Jon Skeet가 문서화한 시간대 변경 및 지역 시간 불연속성의 특별한 경우를 처리하는지에 대한 질문

  • 관련 링크: Stack Overflow
  • Computerphile의 10분짜리 비디오 설명 링크: YouTube

• 날짜/시간 및 암호화 라이브러리를 직접 구축하지 않는 것이 좋음

  • 끝없는 엣지 케이스가 문제를 일으킬 수 있음
  • 새로운 라이브러리를 접할 때 회의적인 이유

• 세 가지 다른 시간 표현/크기가 흥미로움

  • 나노초 정밀도가 수십억 년의 기간 동안 필요한 사용 사례가 궁금함
  • 나노초 정밀도로 ±290년 범위만 제공되는 것이 혼란스러움

• 부호 있는 정수를 사용하는지 여부를 명확히 하는 것이 중요함

  • 문서를 읽어보면 부호 있는 정수일 수도 있고 아닐 수도 있음
  • 부호 있는 정수라면 동일한 날짜와 시간을 나타내는 여러 비트 문자열이 있을 수 있음

• SQLite3에 확장 가능한 타입 시스템이 있었으면 좋겠음

• SQLite의 중요한 누락된 기능을 언급하며 매우 멋지다고 평가함

• 데이터베이스가 단위를 추적해야 한다고 주장함

  • 예를 들어, 시간 열이 float64 초 단위로 나타내는 것을 명시할 수 있어야 함
  • 데이터베이스가 "2h"를 7200.0초로 변환하고 테이블 스캔 중에 비교할 수 있어야 함
  • 과거에 이런 단위 처리를 하는 특수 목적 SQL 데이터베이스를 작성했지만, 이후로 본 적이 없음
  • 시간뿐만 아니라 질량, 부피, 정보, 온도 등 모든 단위를 처리할 수 있어야 함
  • 수학적 오류를 조기에 잡을 수 있도록 데이터베이스가 수학적 무의미한 연산을 거부하도록 가르칠 수 있음

• 나노초 표현과 나노 범위 외의 연도 중 어느 것이 더 유용한지에 대한 질문

  • "정확한" 과학을 하지 않기 때문에 나노초의 가치는 제한적임
  • 역사적 날짜를 나타낼 수 있는 것이 더 자주 필요할 것 같음

• golang 스타일의 유닉스 타임스탬프를 나노초 단위로, 부호 있는 int64로 사용하는 것을 제안함

  • 나노초 정밀도로 수백만 년을 커버할 수 없을 수도 있지만, 정말 필요한지 의문임

• "epoch 이후 초"라는 표현을 정확히 의미하지 않는 한 사용하지 말아야 한다고 주장함

  • 예시 쿼리: select time_sub(time_date(2011, 11, 19), time_date(1311, 11, 18));