この関数は引数としてmktimeを受け取ります。struct tmのメンバーの 1 人はstruct tmですtm_isdst。冬は 1、夏は 0、わからない場合は -1 に設定できます。
ただし、冬の間に を変換しようとすると2009-09-01 00:00、mktime現在は冬ですが、変換しようとしている日付が夏時間であることがわかりません。したがって、結果は 1 時間オフです。私 (GMT+1) にとっては です2009-08-31 22:00が、そうあるべきです23:00。
特定の日付が夏期か冬期かを判断する方法はありますか? 夏の日付を冬の utc に変換することは可能ですか?
（私はこの質問に答えようとしてこの問題にぶつかりました）
これは、標準 Cの時間処理インターフェースの (多くの)欠陥の 1 つです。Olsonタイム ゾーン データベースも参照してください。たとえば、時間帯が冬時間と夏時間 (夏時間と標準時間) の間でいつ切り替わるかを簡単に見つける方法はありません。もちろん、将来のことはすべて予測です。ルール セットは頻繁に変更されます (現在のリリースは2017a です)。
あなたの知る限り、UNIX 固有のソリューションはありますか?
tzcode2017a.tar.gz のコードを調べたところmktime()、tm_isdst を -1 (不明) に設定すると、希望どおりに動作します。したがって、その (パブリック ドメイン) コードを使用する場合は、おそらく問題ありません。Olson コードで配布されている「localtime(3)」からの引用:
Mktime は、tm が指す構造体のローカル時間として表される分解された時間を、time 関数によって返される値と同じエンコーディングを使用してカレンダー時間値に変換します。
tm_wday構造のおよびtm_ydayコンポーネントの元の値は無視され、他のコンポーネントの元の値は通常の範囲に制限されません。(正またはゼロの値を指定tm_isdstするmktimeと、夏時間 (たとえば、米国の夏時間) がそれぞれ指定された時間に有効であると最初に推定されます。負の値を指定するtm_isdstと、mktime指定された時間にサマータイムが有効かどうかを占う関数。この場合、一貫したルールを使用しておらず、後で同じ議論が提示されたときに異なる答えを与える可能性があります.)
「一貫したルール」に関する最後の警告は、タイム ゾーンの仕様が変更された場合 (たとえば、米国が夏時間への変更のために 4 月の第 1 週から 3 月の第 2 週に変更された場合など) は、ルールが変更される前とルールが変更された後の時間を決定した場合、同じ入力データでも異なる出力が得られることがわかりました。
( ftp://ftp.iana.org/tz/tz-link.html などの便利な HTML ファイルがftp://ftp.iana.org/tz/ディレクトリにあることに注意してください。)