▲

Whenever – Python용 타입 및 DST 안전 날짜 및 시간 처리 기술

 (github.com/ariebovenberg)
1P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • Whenever는 Python의 datetime을 개선하여 DST 안전성과 타입 안전성을 제공하는 라이브러리임
  • Rust와 순수 Python으로 사용 가능하며, 성능이 뛰어남
  • Python 표준 라이브러리와 Arrow, Pendulum보다 DST 처리와 타입 안전성에서 우수함
  • 나노초 정밀도와 최신 GIL 개선 사항을 지원하며, Rust 확장을 통해 성능을 향상시킴
  • MIT 라이선스로 제공되며, 피드백을 통해 지속적으로 개선 중임

Whenever 소개

  • Whenever는 Python의 datetime 모듈의 한계를 극복하기 위해 개발된 라이브러리임
  • DST 안전성과 타입 안전성을 제공하여 코드의 정확성을 높임
  • Rust와 순수 Python으로 구현되어 있으며, 성능이 뛰어남

표준 라이브러리의 한계

  • Python의 datetime은 DST를 항상 고려하지 않음
  • 타입 시스템에서 naive와 aware datetime을 구분할 수 없음

다른 라이브러리와의 비교

  • Arrow는 사용자 친화적인 API를 제공하지만, 핵심 문제를 해결하지 못함
  • Pendulum은 일부 DST 문제를 해결했으나, 성능이 저하되고 유지보수가 부족함

Whenever의 장점

  • DST 안전한 산술 연산과 타입 안전한 API 제공
  • 성능이 뛰어나며, Rust 확장을 통해 더욱 향상됨
  • 나노초 정밀도와 최신 GIL 개선 사항을 지원함

빠른 시작

  • Instant, ZonedDateTime, LocalDateTime 등 명시적인 타입 제공
  • DST 안전한 산술 연산과 명시적인 변환 가능
  • ISO8601, RFC3339, RFC2822 형식의 포맷팅 및 파싱 지원

로드맵

  • 0.x 버전: 기능 동등성 확보 및 API 개선
  • 1.0 버전: API 안정성과 하위 호환성 확보

한계

  • 서기 1년부터 9999년까지의 그레고리력 지원
  • IANA TZ DB와 일치하는 시간대 오프셋 지원
  • 윤초는 지원하지 않음

버전 관리 및 호환성 정책

  • Whenever는 시맨틱 버전 관리를 따름
  • 1.0 버전 전까지 API 변경 가능성 있음

라이선스

  • MIT 라이선스로 제공되며, Rust 의존성은 유사한 허가 라이선스 사용

감사의 글

  • Temporal, Noda Time, Joda Time 프로젝트에서 영감을 받음
  • Ruff 프로젝트의 벤치마크 비교 그래프를 기반으로 함
▲
GN⁺ 2일전  [-]
Hacker News 의견
  • 이 라이브러리가 존재하는 이유를 설명하는 블로그 글을 읽어보지 않았다면 추천함. 제목은 "Ten Python datetime pitfalls, and what libraries are (not) doing about it"임
  • 이 라이브러리는 표준 라이브러리의 Liskov 위반 문제를 해결함. 표준 라이브러리에서는 날짜를 비교할 수 있지만, datetime과 날짜를 비교하면 오류가 발생함. 최근에 이 문제로 인해 직장에서 어려움을 겪었음
  • Arrow, Delorean, Pendulum, 표준 라이브러리 datetime을 사용해봤지만, 결국 Whenever를 선택함. 실제로 datetime을 다루는 데 더 적합하고, 더 활발히 유지보수되는 것 같음. 다른 라이브러리들은 항상 엣지 케이스를 놓치고 있다는 느낌이 들었음. Pendulum은 API에 더 깊이 내재되어 있는 것 같음
  • 표준 라이브러리를 사용하고, 문서와 변경 로그를 주의 깊게 읽고, 필요한 기능을 구현하는 사람이 나뿐인가? 의존성이 프로젝트를 망친다는 것을 어렵게 배웠음. 이 라이브러리가 훌륭하지 않다는 것은 아님. 물론 사용 사례가 있음
  • Rust나 순수 Python으로 제공됨. 바이너리 패키지를 사용하거나 빌드해야 하는 복잡성은 성능 이점에 비해 가치가 없음. 순수 Python 버전은 소스에서 빌드하고 특별한 플래그를 전달해야 하므로 requirements.txt에 지정할 수 없음
  • 성능이 최우선이 아니라면 순수 Python 버전도 사용 가능함. 순수 Python 구현의 벤치마크도 보고 싶었음. 만약 Arrow보다 성능이 떨어진다면?
  • Pandas에서 datetime 비교를 추가하지 않는 것이 재미있음. 아마도 다른 라이브러리들보다 더 많은 날짜를 처리하는 데 사용될 것임
  • 성능 문제가 언제 중요한지 아는 사람이 있는가? datetime은 단명 객체로 이해하고 있음. 코드베이스에 수천 개의 datetime 객체가 있는 것은 원하지 않을 것임. 거의 모든 경우 UTC가 충분함. 범위로 필터링/버킷/집계를 해야 할 때 datetime을 tz로 사용하여 필터링/버킷/집계 기준을 설정하고, 이를 UTC로 변환하여 계속 int 비교를 함. Whenever가 처리하는 대부분의 경우는 datetime이 장기 객체일 때일 것임. 그런 필요성을 전혀 느끼지 못함. 클라이언트로부터 tz 입력을 허용하기 위해 사용하고, 도착 즉시 UTC로 변환함. 정말로 tz가 필요하다면 별도로 저장함. 이는 드물게 발생함 (예: 캘린더에서는 tz를 저장해야 하지만, 아마도 모든 UTC 옆에 저장할 필요는 없고 사용자 수준에서 저장해야 함. 또 다른 예는 인력 스케줄링에서 8am-4pm 또는 8pm-4am이 위치에 따라 다른 의미를 가질 수 있음. 이는 더 이상 datetime이 아니라 시간대의 시간임)
  • 기본적인 것 이상을 원할 때 Arrow를 사용함. 이 라이브러리는 꽤 흥미로움. 엣지 케이스의 더 큰 커버리지 때문이 아니라, Rustified 모드와 순수 Python 모드가 모두 제공되기 때문임. Whenever를 사용하면 다른 것을 걱정할 필요가 없고, 프로젝트에서 더 나은 datetime 처리를 원할 때 datetime으로 돌아갈 필요가 없음. Rust 도구 체인이 없는 환경이나 문제가 있는 환경에서도 사용 가능함. Kudos
  • 업계/언어 전반의 테스트 스위트를 만들어야 할 것 같음. 많은 날짜/시간/캘린더 라이브러리를 테스트할 수 있는 것. 브라우저 산성 테스트와 유사하지만 기본 기능에만 초점을 맞춤. 이 새로운 라이브러리가 마음에 듦 (감사합니다) 하지만 이름이 실제와 반대의 의미를 암시함. "Whenever"는 신경 쓰지 않는다는 의미로 들리지만, 실제로는 신경 쓰는 경우에만 사용할 것임. 또한 Shakira, 하하. Hmm, pedantic은 이미 사용 중임. Timely, precise, punctual, meticulous, ahorita, pronto 등. 시간 관련 이름이 마음에 듦. 마지막으로, 이 링크들 중 어느 것도 불변성을 언급하지 않지만, 맨 위에 언급되어야 함
답변달기