Как часто в полночь время unix делится на 10 000 000 секунд?
Если вы хотите сохранить расстояние между полями, которые будут сохранены, вы также можете сделать:
<file awk '{sub(/^[[:blank:]]*([^[:blank:]]+[[:blank:]]+){3}/, ""); print}'
(однако обратите внимание, что не все awkреализации поддерживают {3}, даже несмотря на то, что это POSIX ).
То есть используйте регулярное выражение, которое соответствует первым 3 полям.
Или просто используйте для этого sed:
<file sed 's/^[[:blank:]]*\([^[:blank:]]\{1,\}[[:blank:]]\{1,\}\)\{3\}//'
Те предполагают, что все строки во входных данных имеют как минимум 4 поля.
На входе a b c d <tab>e f <nl>будет вывод d <tab>e f <nl>.
Вы получаете число, кратное10 000 000(или просто 10M )через каждые 10M. Это фактор 1.
Вы добираетесь до полуночи каждые 24 часа (или 86 400 секунд ). Это фактор 2.
Вам нужны числа, кратные 10M и 86400. Это математическая функция, называемая L.C.M. (наименьшее общее кратное ). Вы можете получить результат на этой странице .
Это число270 000 000(или 270M ).
Первый раз это произошло в эпоху 0 секунд (, формально это могло быть спорным ). Или 1/1/1970 12:00:00 UTC.
Краткий список этих событий приведен:
$ for i in $(seq 20); do mult=$((i*270000000)); printf '%12s -- %s\n' "$mult" "$(date -ud @"$mult")"; done
270000000 -- Sun 23 Jul 1978 12:00:00 AM UTC
540000000 -- Wed 11 Feb 1987 12:00:00 AM UTC
810000000 -- Sat 02 Sep 1995 12:00:00 AM UTC
1080000000 -- Tue 23 Mar 2004 12:00:00 AM UTC
1350000000 -- Fri 12 Oct 2012 12:00:00 AM UTC
1620000000 -- Mon 03 May 2021 12:00:00 AM UTC
1890000000 -- Thu 22 Nov 2029 12:00:00 AM UTC
2160000000 -- Sun 13 Jun 2038 12:00:00 AM UTC
2430000000 -- Wed 02 Jan 2047 12:00:00 AM UTC
2700000000 -- Sat 24 Jul 2055 12:00:00 AM UTC
2970000000 -- Tue 12 Feb 2064 12:00:00 AM UTC
3240000000 -- Fri 02 Sep 2072 12:00:00 AM UTC
3510000000 -- Mon 24 Mar 2081 12:00:00 AM UTC
3780000000 -- Thu 13 Oct 2089 12:00:00 AM UTC
4050000000 -- Sun 04 May 2098 12:00:00 AM UTC
4320000000 -- Wed 24 Nov 2106 12:00:00 AM UTC
4590000000 -- Sat 15 Jun 2115 12:00:00 AM UTC
4860000000 -- Tue 04 Jan 2124 12:00:00 AM UTC
5130000000 -- Fri 25 Jul 2132 12:00:00 AM UTC
5400000000 -- Mon 13 Feb 2141 12:00:00 AM UTC
Это время в формате UTC (Универсальное скоординированное время ), которое не показывает Високосные секунды . Это время отличается от Международного атомного времени (TAI)и времени GPS.
Я не знаю, что эти события были названы (и не думаю, что они должны ).
В Википедии есть кое-что по мелочи:
- В 23 :31 :30 UTC в пятницу, 13 февраля 2009 г., десятичное представление времени Unix достигло 1234567890 секунд.
Я повторил от 0000000000 до 9990000000, и это даты, которые вернулись как кратные 10 000 000 в полночь.
for i in $(seq 0 9);do for j in $(seq 0 9);do for k in $(seq 0 9); do DATE="@${i}${j}${k}0000000"; echo $DATE; date --utc --date=$DATE; done; done; done | grep "00:00:00" -B1
@0000000000
Thu Jan 1 00:00:00 UTC 1970
--
@0270000000
Sun Jul 23 00:00:00 UTC 1978
--
@0540000000
Wed Feb 11 00:00:00 UTC 1987
--
@0810000000
Sat Sep 2 00:00:00 UTC 1995
--
@1080000000
Tue Mar 23 00:00:00 UTC 2004
--
@1350000000
Fri Oct 12 00:00:00 UTC 2012
--
@1620000000
Mon May 3 00:00:00 UTC 2021
--
@1890000000
Thu Nov 22 00:00:00 UTC 2029
--
@2160000000
Sun Jun 13 00:00:00 UTC 2038
--
@2430000000
Wed Jan 2 00:00:00 UTC 2047
--
@2700000000
Sat Jul 24 00:00:00 UTC 2055
--
@2970000000
Tue Feb 12 00:00:00 UTC 2064
--
@3240000000
Fri Sep 2 00:00:00 UTC 2072
--
@3510000000
Mon Mar 24 00:00:00 UTC 2081
--
@3780000000
Thu Oct 13 00:00:00 UTC 2089
--
@4050000000
Sun May 4 00:00:00 UTC 2098
--
@4320000000
Wed Nov 24 00:00:00 UTC 2106
--
@4590000000
Sat Jun 15 00:00:00 UTC 2115
--
@4860000000
Tue Jan 4 00:00:00 UTC 2124
--
@5130000000
Fri Jul 25 00:00:00 UTC 2132
--
@5400000000
Mon Feb 13 00:00:00 UTC 2141
--
@5670000000
Thu Sep 4 00:00:00 UTC 2149
--
@5940000000
Sun Mar 26 00:00:00 UTC 2158
--
@6210000000
Wed Oct 15 00:00:00 UTC 2166
--
@6480000000
Sat May 6 00:00:00 UTC 2175
--
@6750000000
Tue Nov 25 00:00:00 UTC 2183
--
@7020000000
Fri Jun 15 00:00:00 UTC 2192
--
@7290000000
Mon Jan 5 00:00:00 UTC 2201
--
@7560000000
Thu Jul 27 00:00:00 UTC 2209
--
@7830000000
Sun Feb 15 00:00:00 UTC 2218
--
@8100000000
Wed Sep 6 00:00:00 UTC 2226
--
@8370000000
Sat Mar 28 00:00:00 UTC 2235
--
@8640000000
Tue Oct 17 00:00:00 UTC 2243
--
@8910000000
Fri May 7 00:00:00 UTC 2252
--
@9180000000
Mon Nov 26 00:00:00 UTC 2260
--
@9450000000
Thu Jun 17 00:00:00 UTC 2269
--
@9720000000
Sun Jan 6 00:00:00 UTC 2278
--
@9990000000
Wed Jul 28 00:00:00 UTC 2286
Это происходит каждые 270000000 секунд, что выходит каждые 3125 дней.
В принципе, вы ищете наименьшее общее кратное секунд в сутках (24·60·60=86400=2⁷·3³·5² )и 10⁷=2⁷·5⁷, что равно 2⁷ ·3³·5⁷.
Когда вы разделите 2⁷·3³·5⁷ на количество секунд в сутках, вы получите
2⁷·3³·5⁷
-------- = 5⁵
2⁷·3³·5²
, что, в свою очередь, равно просто 5⁵=3125 дней.
Конечно, реальность менее гладкая. Если вы учтете тот факт, что «полночь» зависит от високосных секунд, вы быстро заметите, что вам придется определять, в зависимости от того, какой способ отсчета времени вы задаете, этот вопрос :UTC не то же самое, что система GPS время, и оно может не совпадать со временем, отображаемым на ваших часах, и не совпадать с тем временем, которое Google использует внутри компании¹.
¹ многие люди аплодируют Google за «решение» проблемы непротиворечивости секунд координации путем «растягивания» времени на более длительный период (в день ). Я лично ненавижу, что :вместо того, чтобы реализовать то, что необходимо для согласования времени со всеми остальными, вы возитесь со своими часами. Все остальные решают эту проблему в больших масштабах :Google, -провозгласившие себя «планетарными» вычислениями, не так уж сложны в плане синхронизации, если сравнить их с тем, что операторы мобильных сетей делают во всем мире уже более трех десятилетий. сейчас.