GOOGLE ADS

Dienstag, 12. April 2022

Verkettung von localtime und mktime in jq

Wenn ich mache:

$ jq -cn 'now | localtime'
[2022,3,12,21,9,29.65448808670044,2,101]

Es gibt korrekt die "unterbrochene Zeit"-Darstellung der aktuellen Ortszeit an.

Aber wenn ich es mache:

$ jq -cn 'now | localtime | mktime | localtime'
[2022,3,13,7,10,36,3,102]

Es gibt eine "unterbrochene Zeit"-Darstellung zurück, die sich von der aktuellen Ortszeit unterscheidet.

Ich denke, wenn die Ausgabe von localtimeseit der Unix-Epoche in Sekunden konvertiert wird mktime, wird sie falsch konvertiert, weil sie fälschlicherweise GMT-Zeit annimmt?

Wenn ich mache:

$ jq -cn 'now | gmtime | mktime | localtime'

Jetzt liefert dies korrekte Ergebnisse (ergibt eine "unterbrochene Zeit"-Darstellung der aktuellen Ortszeit).

Hab ich recht? Vielen Dank.


Lösung des Problems

Ja.

Aus den jq-Dokumenten:

Die mktimeeingebaute Funktion verbraucht "unterbrochene Zeit"-Darstellungen der Zeitausgabe durch gmtimeund strptime.

Sie haben ursprünglich eine Ortszeit übergeben, es wird jedoch eine UTC-Zeit erwartet. Wie Sie vermutet haben, ist Ihr ursprünglicher Code aus diesem Grund fehlgeschlagen und der letztere Code hat funktioniert. jq mktimeist die Umkehrung von gmtime. [1]

$ jq -rn 'now |., ( gmtime | mktime )'
1649770973.430903
1649770973

jq scheint kein Mittel zu bieten, um von einer Ortszeit in eine Epochenzeit umzuwandeln. [2]

  • Dies unterscheidet sich vom Verhalten von C's mktime. C's mktimeerwartet eine Ortszeit und ist damit das Gegenteil von localtime.


  • Kann in C mktimebeide Rollen übernehmen. Während es normalerweise von der Ortszeit konvertiert, kann es auch von UTC konvertieren, indem die lokale Zeitzone auf UTC eingestellt wird.

  • Keine Kommentare:

    Kommentar veröffentlichen

    Warum werden SCHED_FIFO-Threads derselben physischen CPU zugewiesen, obwohl CPUs im Leerlauf verfügbar sind?

    Lösung des Problems Wenn ich das richtig verstehe, versuchen Sie, SCHED_FIFO mit aktiviertem Hyperthreading ("HT") zu verwenden, ...