2024年3月30日以降にどのように1日がありますか?

2024年3月30日以降にどのように1日がありますか?

私はEU +1にいるか、いつ夏時間有効、+2。 2024年3月31日日曜日です。今日の日曜日の朝には夏時間制である2→3(CET-4中央ヨーロッパ夏時間)。

私のLinuxサーバーは別のネットワークにあり、毎月最後の日の23:58に毎月のエネルギー消費量を報告します。彼らは何年も完璧に働いてきました。ネットワーク間の移動時間は最大8時間です!

各サーバーには1つリアルタイムクロックそして同期NTP頻繁に。疑わしいことがある場合は、各ネットワーク上の3つのコアサーバーがすべて(時間を含む)が大丈夫かどうかを常に確認するなど、多くの安全装置があります。はい、私は編集証です。私は(0)エラーを受け入れません。私のシステムは長年にわたって完全かつ安定して実行されています。働きました、ごめんなさい。

昨夜3月30日23時58分、私のすべてのRaspberry Piサーバーは3月30日を来月1日に決めました!各ネットワークに対して7つの異なる独立した方法を確認しましたが、すべてが実際に3月30日23:58分に発生しました!確認には、DSTを無視する9つの独立したデバイスと外部の米国およびEUメールプロバイダが含まれます。

毎日23:58に私のサーバーはbashテストを実行しますが、テストは明らかにさまざまな点で間違っている可能性があります。

(( $(date -d tomorrow +"%-d") == 1 )) && ZadnjiDanMjeseca=1 || ZadnjiDanMjeseca=""

今回のテストでは何の問題もないようです!私が間違っていることを願っています。今この時、2024年3月31日。すべてがうまくいきます。 zdumpが正しいです! (次の例は私が見るのに間違っているようです。4つの異なる行を表示する必要があります。)

hwclock; date; date -d tomorrow +"%-d"
2024-03-31 19:22:23.311664+02:00
ned, 31.03.2024.  19:22:23 CEST
1

この問題を説明する唯一の方法は、私が使用しているLinuxディストリビューションです。ラズベリーパイとにかく、2つの独立したカーネル関数の計算時間があります。残念ながら、そのうちの1人は今年がうるう年であるという事実を逃しました! UPS!

それでは、なぜこのRaspberry Pi OSのバージョンとカーネルに限定されていますか?世界では、MicrosoftはExcelでうるう年を正しく計算できませんでした!

今週末、私たちの国のいくつかの機関(銀行、州税務署...)に日付関連の問題があり、店舗も閉鎖していますが、これはRaspbianに限定されないようです。

これはプログラマーとして私にとっては良くありません。しかし、他の説明が見つかりません。私が間違っていることを願っています...

投稿する前には1日23時58分から00時3分に切り替えて末日23時58分にデータを記録しなければならず、+1日を要求する代わりに300秒を追加してテストを行いました。これらの解決策はうまくいくでしょう。

だからコメントに隠されていません。私はそのような計算を使用したことがないので、「明日」は実際に明日を意味すると期待する基本的な間違いを犯しました!これは私には意味がありません。これは+1日を意味します。したがって、私はこれら2つのコマンドが同じ出力を生成すると予想しました。

> date -d 'next tue'
uto,  2.04.2024.  00:00:00 CEST

> date -d 'tomorrow'
uto,  2.04.2024.  10:24:55 CEST

次のように入力する代わりに:

date -d "tomorrow 0"

ベストアンサー1

わかりました。

# date -s '2024-03-30 23:58'; date -d tomorrow
Sat Mar 30 23:58:00 EET 2024
Mon Apr  1 00:58:00 EEST 2024

2024-03-30 23:58以来24時間だから驚くべきことではありません。はい2024-04-01 00:58。後者にのみ夏時間が適用されます。

マニュアルによると:

関連項目は、日付を前後に(またはない場合は現在の日付)調整します。関連プロジェクトの影響は累積されます。
[...]
より正確な単位は[...]で、「日」は24時間に対応し、
[...]
文字列「明日」は将来の1日に対応します(「日」に相当) 。 、
[.. .]
関連プロジェクトによって生成された日付が時計調整境界(通常は夏時間)を超えた場合、生成された日付と時刻はそれに応じて調整されます。

この問題を回避する方法は、真夜中に近い時間を要求することです。

たとえば、正午は通常正しい曜日です。

# date -s '2024-03-30 23:58'; date -d '+12 hours'
Sat Mar 30 23:58:00 EET 2024
Sun Mar 31 12:58:00 EEST 2024 

これも動作するようです:

# date -s '2024-03-30 23:58'; date -d '12:00 tomorrow'
Sat Mar 30 23:58:00 EET 2024
Sun Mar 31 12:00:00 EEST 2024

おすすめ記事