☰

修正する

tag-icon • tag-icon date timezone
修正する

シンボリックリンクは/etc/localtime次のとおりです。

===> ls -l /etc/localtime 
... /etc/localtime -> /usr/share/zoneinfo/Europe/Berlin

環境変数にこの情報を提供する必要がありますTZ。

これは働きます:

===> TZ=US/Pacific last reboot| head
reboot   system boot  4.4.0-34-generic Thu Aug 25 02:12   still running
reboot   system boot  4.4.0-34-generic Wed Aug 24 02:14   still running

しかし、次はそうではありません。

===> TZ=Europe/Berlin last reboot| head
reboot   system boot  4.4.0-34-generic Thu Aug 25 11:12   still running
reboot   system boot  4.4.0-34-generic Wed Aug 24 11:14   still running

しかし、それは（fromウィキペディアタイムゾーン)

===> TZ=DE last reboot| head
reboot   system boot  4.4.0-34-generic Thu Aug 25 09:12   still running
reboot   system boot  4.4.0-34-generic Wed Aug 24 09:14   still running

TZリンクに基づいて設定方法を検索してみました/etc/localtime。

これは自動化され、すべてのタイムゾーンで機能するはずです。

最後 - バージョン：util-linux 2.27.1

===> cat /etc/adjtime
0.0 0 0.0
0
LOCAL

修正する

内部データベースの履歴が間違っているようです。

root     pts/20       127.0.0.1        Thu Aug 25 13:29 - 13:29  (00:00)
modwork_ pts/17       127.0.0.1        Thu Aug 25 10:38 - 11:37  (00:59)
modwork_ pts/18       127.0.0.1        Thu Aug 25 10:05 - 10:19  (00:13)
tguettle tty7         :0               Thu Aug 25 09:12    gone - no logout
reboot   system boot  4.4.0-34-generic Thu Aug 25 11:12   still running

答え1

ハードウェアクロックはUTCではなく現地時間で実行されるため、ブートタイムスタンプが誤って保存されます。 （これはLOCALの項目です/etc/adjtime。）lastこれは調整されていないため、表示される開始時間は、タイムゾーンとUTC（現在のベルリンでは2時間）の違いによって変わります。ハードウェア時計をUTCに変更する以外に、この問題を解決する方法はないと思います！

この答えの残りの部分は実際の質問とは関係ありませんが、とをTZ考慮するとまだ関係があります/etc/localtime。

通常、ファイルベースの値を使用するには、TZファイル名の前にプレフィックスを付ける必要があります:（参照tzset(3)細部）:

TZ=:Europe/Berlin last reboot|head

これはとして使用できるすべての項目に適用されます。/etc/localtime必要に応じてデフォルトのTZDIR場所をオーバーライドするために使用できます（/usr/share/zoneinfo）。

（これはglibc;を使用してLinuxを実行すると仮定し、:実装によって異なります。POSIXで定義。 Linuxでは、:両方のフォーマットが試されているため、通常は必要ありませんTZ。 )

答え2

アメリカ/太平洋8月25日木曜日02:12 はいヨーロッパ/ベルリン8月25日木曜日11時12分、ベルリン時間は米国太平洋標準時より9時間早いからです。

$ TZ=US/Pacific date -d 'Thu Aug 25 02:12' +%s
1472116320
$ TZ=Europe/Berlin date -d 'Thu Aug 25 11:12' +%s
1472116320

UTCオフセットを見る：

$ TZ=Europe/Berlin date +%z
+0200
$ TZ=US/Pacific date +%z
-0700

2番目の例働く。これは3番目ではありません。働く。

TZ=DE標準（XXX[offset][YYY[dstoffset]]）領域定義は2つの文字にすぎず、/ usr / share / zoneinfoに呼び出されるファイルがない可能性があるため無効であるため、DEデフォルトはUTC時間です。

$ TZ=DE date +%z
+0000

ベルリン時間9時12分（たとえば、Unix時間1472109120）でシステムを起動した場合、これはこのエントリが追加された時点よりも時計が2時間遅れたことを意味しますwtmp。

initこれは、システムが起動したときに最初に行うことの1つです。これは通常、ネットワーク時間同期サービス（時計の変更）が開始される前です。あなたの他正しいwtmpエントリは、最初の人がログインしたときに時計が固定されたことを示します。

システムがマルチブートで、他のシステムの1つがMicrosoftによって作成されている場合、MicrosoftシステムはデフォルトでハードウェアクロックをUTCの代わりに現地時間に設定するため、バグ/バグ機能があることに注意してください。したがって、Unix シリーズのオペレーティング システムでハードウェア クロックを UTC と想定すると競合が発生し、Microsoft オペレーティング システムから起動すると、オペレーティング システムはハードウェア クロックを UTC から現地時間に変換しようとします。 Unix オペレーティングシステムはその逆を実行します。

~によるとそこ、不可能に見える固定するこれはMicrosoft OSなので、Unix OSにハードウェアクロックを（Windowsと同様に）現地時間に設定するように指示してこの問題を解決し、すべてのOSが現地時間の意味に同意することを確認する必要があります。 (e) DST 変更中は、システムをシャットダウンしたり再起動しないでください。たとえば、現在のDebianシステムではinUTCに変更LOCALできます/etc/adjtime。

これadjtimeが含まれているので、LOCALその仮定は削除されます。他の可能性：時計がUTCに設定されている別のシステムがある場合、または現地時間がUTCに設定されているMicrosoftシステム。LOCALに変更すると、UTC問題が解決する可能性があります。

あるいは、より一般的には、システム内のすべてのオペレーティングシステムがハードウェアクロック設定の場所に同意するようにします。

関連情報