#夏時間プログラミングの基本

Kazuho Oku @kazuho

夏時間への移行は、ある標準時から別の標準時への変更（例: 東部標準時-5から東部夏時間-4への変更）として表現するんだよ。標準時のUTCに対するオフセットが変化するんじゃないよ #夏時間プログラミングの基本

Kazuho Oku @kazuho

時刻間の差の計算は、とにかく同一の標準時に変換してから計算する。実務的にはUTCに変換して計算すればいい #夏時間プログラミングの基本

Kazuho Oku @kazuho

一番問題になるのは「毎日午前９時」とかローカル時刻にひもづいている繰り返しイベント。夏時間を含む複数時間帯前提のプログラムだと、値がローカル時刻かを表すフラグと、ローカル時刻の場合はどの地点か（例: Asia/Tokyo）を表す属性をもってる #夏時間プログラミングの基本

Kazuho Oku @kazuho

実務的には、ローカル時刻依存のイベントを増やすのは夏時間移行の問題を増やすだけなので、できるだけ多くの繰り返しイベントをUTCベースで設計して、窓口対応など人に関係する部分だけをローカル時刻連動にする #夏時間プログラミングの基本

Kazuho Oku @kazuho

これ、こうするのは、ある標準時を採用している地域のうち、一部のみに夏時間があるケースがあるから。例えばオーストラリア東部時間(AEST)を採用してる4州のうち3州は夏時間(AEDT)に移行し、1州は夏の間もAESTを使い続ける #夏時間プログラミングの基本 twitter.com/kazuho/status/…

まぐろ @mag6_

話題のサマータイム、どう対応すれば良いのか #夏時間プログラミングの基本 でつぶやかれてる

Kazuho Oku @kazuho

例えば東京時刻で2018/8/14 9:00AMから毎日10回繰り返すイベントはiCalendarでは "DTSTART;TZID=Asia/Tokyo:20180814T090000 RRULE:FREQ=DAILY;COUNT=10" のように表現されます。絶対値としてのタイムゾーンはでてこないことがわかるかと思います #夏時間プログラミングの基本

Kazuho Oku @kazuho

#夏時間プログラミングの基本 を連ツイしたのは、第一に、OSやJVMなどが提供する夏時間サポートと異なる手法によるオレオレ手法によるサマータイム実装を考え、それを前提とした技術的妥当性を欠くサマータイムへの批判がいくつか見受けられたこと

Shirouzu Hiroaki（白水啓章） @shirouzu

#夏時間プログラミングの基本 を見て思い出したが、FATのようにローカル時間で記録するファイルシステムがあり、NTFSとの差分コピー時に更新ファイルと誤認識される問題もあったり。 （なので、robocopy等は1時間の誤差を無視するオプション(/DST)が存在）

Kazuho Oku @kazuho

OS等の夏時間機能にのっかる最大のメリットは、いつ時間帯が切り替わるか（例：３月第２日曜日午前２時）を指定するデータベースを自分で設計管理更新しなくていい点。時間帯の導入廃止や切替時期が法律で変わるから、ハードコードするわけにはいかないんですよね #夏時間プログラミングの基本

よう @youchan

#夏時間プログラミングの基本 サマータイムへの対応、そもそもローカル時間しか考慮されていないシステムが多数存在することが問題になりそう。

ず @zu2

“ハッシュタグ #夏時間プログラミングの基本” htn.to/Q78ZsXX

Kazuo Dohzono @dohzono

電波時計では (UTC でなく) JST でアナウンスされるし、これに基づいた屋外設置データロガー等で最も多い要望は「旧来通りの形式で記録せよ」と思われる。夏時間対応としてここに UTC を持ち込むべきかどうかは判断が難しい。 jjy.nict.go.jp/jjy/trans/inde… #夏時間プログラミングの基本

Hayato Tsutsumi @2t3

これから2年かけて2時間加速する？ #夏時間プログラミングの基本