パスワードを忘れた? アカウント作成
13676356 journal
日記

acountnameの日記: unix鯖のrootってUTC? JST? Asia/Tokyo? 9

日記 by acountname

unix系はusrレベルでコマンドを使わせてもらってるだけで鯖運用は本職じゃないから今まで考えもしなかったのだが、すでにサマータイムを運用している国ではrootさんってTZを何にしてるんだろう?
cronなんかで間違っても1日(24H)に2回動いちゃいけないとか、ぜったい24H間隔じゃないとデータがダメになるようなものもありそうだ。そういうのがDST突入/脱出時にどういう処置をしているのか、いまになって気になってきた。

UTC 00:00に合わせて +0900 ---> +1100 にするとして、午前9時になったら午前7時(D)になるわけだ。脱出の日は +1100 ---> +0900 になるから午前9時(D)から午前7時になる。
突入のその日、午前6時に出社するシフトの人と午前10時に出社する人との時間差は4時間→6時間になって不公平感すごい。ぜったい午前10時出社のシフトは午前8時(D)に変更されるだろうな、日本式の会社だし。 あれ、、、通勤2時間ちょいかかるひとは何時に家を出りゃいいんだ?

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by acountname (43053) on 2018年08月11日 17時16分 (#3460029) 日記

    ( +1100 にしちゃダメじゃん、 +0900 --> +0700 , +0700 --> +0900 じゃないと )

  • by Anonymous Coward on 2018年08月10日 18時57分 (#3459526)

    UNIXの事は man を読めば解ります

    man 5 localtime
    man 1 timedatectl

    cronの方はCRON_TZという変数でタイムゾーンを固定できます

    不公平感すごい、については
    サマータイム開始日と終了日は同じ人がシフトに入れば
    損得が相殺されます

    • timedatectlはUNIXの事とは言いがたいんじゃない?

      親コメント
    • by acountname (43053) on 2018年08月11日 9時56分 (#3459833) 日記

      Solarisェ……
      (それともmanが古いだけ?)

      :~ $ man CRON_TZ
      マニュアルには CRON_TZ のエントリがありません。
      ~ $ man 5 localtime
      マニュアルには 5 のエントリがありません。
      マニュアルを清書中です。しばらくお待ちください... 終了

      Standard C Library Functions ctime(3C)

      NAME
                ctime, ctime_r, localtime, localtime_r, gmtime, gmtime_r,
                asctime, asctime_r, tzset - convert date and time to string

      SYNOPSIS
                #include

                char *ctime(const time_t *clock);

                struct tm *localtime(const time_t *clock);

      親コメント
  • by Anonymous Coward on 2018年08月11日 1時51分 (#3459765)

    午前二時から三時には起動しないようにする。
    これで特に問題起きないと思うけど。

    録画予約の事故が起きないように、当該時刻帯はテレビショッピングか、1時間ドラマの「同じ話」を再放送するとか
    こまかーいノウハウはあるんだよ

    • 「ある時点から24時間以内に何をどれだけする予定か」を、けっこう厳密に計らねばなりません。24時間を、これまではJSTで十分でしたが、サマータイム考えるとやっかいすぎ。
      サマータイムでなくても、今後、世界に出るならば時刻の登録が現地時刻になるだろうし、いまさらながら日本だけ専用のプログラム部分を直さねばならないと、背筋に冷や汗が流れ(てくれれば涼しいんだろが、実際は脂汗)

      親コメント
  • by Anonymous Coward on 2018年08月11日 8時03分 (#3459796)

    米国西海岸在住(PDT/PST の時間帯に含まれる場所)の米国人です。

    私が管理しているサーバ(80 台程度)は全部 UTC にしています。

    前任者時代は会社がシカゴだったので最初は米国中部 CST/CDT 時間で管理していました。やがて、会社ごと米国西海岸に引っ越しましたが、サーバの設定を不用意に変えることが出来ずそのまま使っていました。私が入社したのはその頃でしたが、OS のバージョンアップをする際に、サーバは UTC にすべしと(強固に)主張し、それが通って今に至ります。

    米国では4つのタイムゾーンがあり、従業員も様々なタイムゾーンに住んでいます。また、自社サービスのユーザは全世界にいるので、それぞれのタイムゾーンに対応する必要があります。またサマータイムによって年に一回だけ23時間の日と25時間の日があったりで、色々と面倒です。

    これらから、サーバの中は全部 UTC で管理し、UI で時間を出すときにエンドユーザのタイムゾーンに対応に合わせる、という風にしています。内部時間と外部時間という感じでしょうか。エンドユーザのタイムゾーンは IP アドレスから推定する有料サービスで得ています。

    この仕組みですと、まず UTC なのでサマータイムの問題がありません。さらに、エンドユーザのタイムゾーンから UTC に変換するときと、UTC からエンドユーザのタイムゾーンに変換すべきときが明確で、間違いを起こしづらいです。それ以外の内部での時間管理やサードパーティーとの通信は全て UTC でやりとりするので、サマータイムやら、日付が変わるタイミングの統一やらが簡単です。[*1] また、エンドユーザの地域がどこであったとしても、必ず同じように時間変換をしないといけないので不具合が起きづらいです。[*2]

    [*1] 例えば、分析機能を提供するサードパーティが「昨日広告をクリックしたユーザは 300,000 人だよ」とレポートをくれたとして、その「昨日」が厳密に何時から何時までなのか知らないと分析がしづらいです。それが弊社内部と同じ時間帯だと都合が良いので、全てのサードパーティーで「日替わりのデータは UTC 基準にしてくれ」と設定しています。

    [*2] 例えば、タイムゾーンが US/Pacific のサーバだったとすると、「もしエンドユーザが US/Pacific ならば時間変換なし。そうでなければ、US/Pacific からエンドユーザのタイムゾーンに時間変換すべし」となります。開発者が US/Pacific 在住の場合、これを忘れたときの不具合に気づきづらいです。サーバが UTC だと、エンドユーザのタイムゾーンに関係なく「UTC からエンドユーザのタイムゾーンに変換すべし」となり、if-else の分岐文がありません。間違えにくいです。

    • ご教示有難うございます。

      うーん、やはりUTCかな。
      正直なところ、もしも政府が正気ならサマータイムは否決されるはずなんで、それほどは心配してないですけど、ウチが今後なんかの拍子に世界中に手を出すことになったらどうしたもんかとは悩んでいました。
      今までは日本から出るつもりもなかったからプログラムソースの中身も日本語だらけだしなあ……メッセージボックスの直書きも全部リソース化しないと……何年かかるんだ、これ。

      あと英語のコメントなんて書けないぞ ;; (←英語はなんとか読めるようになったけど、いまだに書けない. )

      親コメント
typodupeerror

UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア

読み込み中...