時を正しく扱うためのシステム設計 accepted

Abstract

日本は今年5月に令和元年を迎えました。
元号をデータとして保存していたシステムは改元を乗り越えられたのでしょうか。

新元号が改元のわずか1ヶ月前に発表されるという事態に、システム業界が騒然となっていたことは記憶に新しいかと思います。

この前例から、元号をデータで保存すべきではないと、我々は学ぶことができます。
この学びは当たり前のことで既知のように思われるかもしれません。
しかし、例えば5年前の時点において、サマータイムが日本に導入される可能性を想定できたエンジニアが一体何人いるのでしょうか?

時間・時刻・日時の概念は現実に存在し、覆すことが不可能な絶対の仕様なのです。

タイムゾーン?サマータイム?
うっ、頭が…!

詳細

サブスクリプションと呼ばれる定期購読型のサービスが普及してきました。
Adobe Creative Cloud、Google Drive、iCloud、Dropboxなど、一度は利用したことがあると思います。

サブスクリプションをシステムで実現する場合にも、時間の取扱いはとても重要です。途中解約の日割り計算など、時間にまつわる仕様が数多く存在します。
多くのサブスクリプションに月額プランがありますが、厄介なことに1ヶ月間の日数は30日であったり31日であったりします。

1月29日の1ヶ月後とは、何月何日なのでしょうか?
(2月に29日は存在しません。4年に1度を除いて…)

本発表は、サブスクリプションのシステム開発を通じて得られた時間にまつわる学びを共有すると共に、時を正しく扱うことの難しさと、我々が選択した設計についてお話します。

主なトピック
  • フロントエンド・バックエンド間の時間のプロトコル
  • アプリケーションにおける時間の処理
  • データベースへ保存するときの時間のデータ形式
対象者
  • サブスクリプションのサービスを利用したことがある方
  • サブスクリプションのシステム設計に興味のある方
  • 時間処理のバグに苦しんだことのあるシステム開発者
  • 時間は全てUNIXタイムスタンプで保存すればよいとお考えのシステム開発者

Session Information
Confirmed confirmed
Starts On 8/31/19, 3:50 PM
Room Seminar Room 1204
Session Duration 20 min session
Spoken Language Japanese
Interpretation Unavailable
Slide Language Japanese