Почему 01.01.1970 - «эпохальное время»?

Question

Почему 01.01.1970 - «эпохальное время»?

416

Почему

1 января 1970 года 00:00:00

рассматривалось время эпохи?

rahul 07 июль 2009, в 09:35

Источник

20

Не уверен, почему кто-то думал, что это субъективно. Время эпохи - это стандартная схема отметок времени.
ConcernedOfTunbridgeWells 07 июль 2009, в 08:40
0

nb этот вопрос был опубликован @phoenix, я только исправил грамматику.
Matt Howells 07 июль 2009, в 09:24
5

Сегодня это было 380 000 часов назад
mplungjan 08 май 2013, в 12:06
20

Мы должны начать отсчитывать время с этой даты, поэтому мы сейчас на 44-м году.
Leonardo Raele 28 апр. 2014, в 21:00
3

Сегодня, прямо сейчас, это 1499969999! Это всего лишь ок. 8 часов осталось!
Dr Beco 13 июль 2017, в 18:20
0

Почему время Unix начинается в 1970-01-01?
phuclv 03 март 2019, в 10:11
0

@ LeonardoRaele Да! тогда, например, Вторая мировая война началась в 31 году нашей эры!
Siavash Mortazavi 26 март 2019, в 15:17

Показать ещё 5 комментариев

Теги:

unix

time

epoch

5 ответов

49

History.

Самые ранние версии Unix-времени были 32-битное целое число, увеличивающееся на скорость 60 Гц, которая была системные часы на оборудовании ранние системы Unix. Значение 60 Гц в некоторых программах интерфейсов. Эпоха также отличается от текущего значения. The Руководство для программистов Unix для первого издания от 3 ноября 1971 года определяет Unix время как "время с 00:00:00, 1 января 1971 г., измеренная в шестидесятых годах второй".

Stu Thompson 07 июль 2009, в 08:50

1

Время эпохи - 1 января 1970 года, а не 1 января 1971 года.
Steve Harrison 07 июль 2009, в 07:56
75

@ Стив: Исторически, он прав, ты не прав. ;-)
Stobor 07 июль 2009, в 08:13

8

http://en.wikipedia.org/wiki/Unix_time#History немного объясняет происхождение времени Unix и выбранной эпохи. Определение времени unix и даты эпохи прошло через пару изменений, прежде чем стабилизировать то, что оно сейчас.

Но он не говорит, почему именно 1/1/1970 был выбран в конце.

Заметные выдержки со страницы Википедии:

Руководство по программированию Unix первого издания от 3 ноября 1971 года определяет время Unix как "время с 00:00:00, 1 января, 1971, измеренное в шестидесятые секунды".

Из-за ограниченного диапазона, эпоха была переопределена более одного раза, прежде чем скорость была изменена на 1 Гц, а эпоха была установлена на ее текущее значение.

Несколько более поздних проблем, включая сложность настоящего определения, являются результатом времени Unix, которое было определено постепенно с использованием, а не полностью определено для начала.

Dawie Strauss 07 июль 2009, в 07:54

0

Справочная дата эпохи

Ссылочная дата эпохи - это точка на временной шкале, с которой мы считаем время. Моменты до этой точки считаются с отрицательным числом, моменты после - с положительным числом.

Много эпох в использовании

Почему 1 января 1970 года 00:00:00 считается временем эпохи?

Нет, не эпоха, а эпоха. Есть много эпох в использовании.

Этот выбор эпохи является произвольным.

Основные компьютерные системы и библиотеки используют любую из нескольких дюжин различных эпох. Одна из самых популярных эпох, известная как Unix Time, использует момент UTC 1970 года, который вы упомянули.

Несмотря на популярность, Unix Times 1970, возможно, не самый распространенный. Кроме того, наиболее распространенными будут 0 января 1900 года для бесчисленных электронных таблиц Microsoft Excel и Lotus 1-2-3 или 1 января 2001 года, используемые каркасом Apples Cocoa на более чем миллиарде компьютеров iOS/macOS по всему миру в бесчисленных приложениях. Или, может быть, 6 января 1980 года используются GPS- устройства?

Многие детали

Различные системы используют разную степень детализации при подсчете времени.

Даже так называемое "Unix Time" варьируется: некоторые системы считают целые секунды, а некоторые - миллисекунды. Многие базы данных, такие как Postgres, используют микросекунды. Некоторые, такие как современная инфраструктура java.time в Java 8 и более поздних версиях, используют наносекунды. Некоторые используют еще другие детали.

ISO 8601

Поскольку в использовании эталона эпохи и гранулярности существует так много различий, как правило, лучше избегать передачи моментов в виде отсчета от эпохи. Между неоднозначностью эпохи и гранулярностью, а также неспособностью людей воспринимать значимые значения (и, следовательно, пропускать ошибочные значения), используйте простой текст вместо цифр.

Стандарт ISO 8601 предоставляет обширный набор практичных, хорошо разработанных форматов для выражения значений даты и времени в виде текста. Эти форматы легко разбираются на машине, а также легко читаются людьми в разных культурах.

Они включают:

Дата только: 2019-01-23
Момент в UTC: 2019-01-23T12:34:56.123456Z
Момент со смещением от UTC: 2019-01-23T18:04:56.123456+05:30
Неделя на основе года: 2019-W23
Порядковая дата (с 1-го по 366-й день года): 2019-234

Basil Bourque 21 янв. 2019, в 03:07

-10

Короткий ответ: Почему бы и нет?

Более длинный ответ: само время не имеет значения, если все, кто его использует, согласны с его значением. Поскольку 1/1/70 используется так долго, использование этого кода сделает ваш код максимально понятным для максимально возможного количества людей.

Нет никакой большой пользы в выборе произвольной эпохи, чтобы быть другим.

PaulJWilliams 07 июль 2009, в 09:38

1

Но почему 1970 выбран в качестве года.
rahul 07 июль 2009, в 07:43
37

Потому что Unix был разработан в 1969 году и впервые выпущен в 1971 году, и поэтому было разумно предположить, что ни одна машина не должна будет представлять системное время раньше, чем 1970-01-01-00: 00: 00.
Jörg W Mittag 07 июль 2009, в 07:57
3

Как разработчик исторических игр-симуляторов, кажется довольно глупым, что разработчики некоторых объектов времени склонны считать, что все программы захотят представлять даты только в будущем или недавнем прошлом. Конечно, мы можем программировать наши собственные представления или работать с поправочным коэффициентом, но все же.
Dronz 06 фев. 2013, в 22:51
8

Та же проблема до эпохи относится к «практическому» неигровому использованию, такому как бизнес-таблицы, представление научных данных, пользовательские интерфейсы машины времени и т. Д.
Lenoxus 03 март 2014, в 15:51
6

@Dronz Вы должны принять во внимание, что это было разработано для компьютера за 72000 $ с 9 КБ ОЗУ, который использовал транзисторы и диоды для логических элементов в качестве процессора (никаких микросхем в то время!). Так что не было глупо делать самую основную вещь, которая работала.
Camilo Martin 05 март 2015, в 17:38
0

@CamiloMartin Я понимаю, почему это было использовано около 1970 года, и для типов, которые когда-либо будут представлять только времена компьютерной системы. К сожалению, это делает эти библиотеки менее полезными для других приложений.
Dronz 05 март 2015, в 19:13
0

@Dronz Я нахожу понятие «секунды с 1970» достаточно пригодным для использования (сортируемым, простым, легко выполняемым арифметикой и может быть сохранено в int), но когда этого недостаточно, большинство языков имеют лучшую инкапсуляцию для дат и времени , Это все еще широко используется, потому что людям нравится использовать это, но альтернатива всегда за углом.
Camilo Martin 15 март 2015, в 15:24
2

ОП на мета-уровне верна, схемы, которые мы разрабатываем для времени, всегда были довольно произвольными. Количество дней в году, количество дней в месяце, год "0" и правила для високосного года ... сумасшедшие. Каждая система - это просто серия дурацких компромиссов, потому что это было лучшее, что они могли сделать с доступной технологией и работали достаточно хорошо для их непосредственного использования. Что верно для всех инженерных проектов:)
Indolering 21 окт. 2016, в 23:03

Показать ещё 6 комментариев

Ещё вопросы

Не уверен, почему кто-то думал, что это субъективно. Время эпохи - это стандартная схема отметок времени.
nb этот вопрос был опубликован @phoenix, я только исправил грамматику.
Сегодня это было 380 000 часов назад
Мы должны начать отсчитывать время с этой даты, поэтому мы сейчас на 44-м году.
Сегодня, прямо сейчас, это 1499969999! Это всего лишь ок. 8 часов осталось!
Почему время Unix начинается в 1970-01-01?
@ LeonardoRaele Да! тогда, например, Вторая мировая война началась в 31 году нашей эры!
Время эпохи - 1 января 1970 года, а не 1 января 1971 года.
@ Стив: Исторически, он прав, ты не прав. ;-)
Но почему 1970 выбран в качестве года.
Потому что Unix был разработан в 1969 году и впервые выпущен в 1971 году, и поэтому было разумно предположить, что ни одна машина не должна будет представлять системное время раньше, чем 1970-01-01-00: 00: 00.
Как разработчик исторических игр-симуляторов, кажется довольно глупым, что разработчики некоторых объектов времени склонны считать, что все программы захотят представлять даты только в будущем или недавнем прошлом. Конечно, мы можем программировать наши собственные представления или работать с поправочным коэффициентом, но все же.
Та же проблема до эпохи относится к «практическому» неигровому использованию, такому как бизнес-таблицы, представление научных данных, пользовательские интерфейсы машины времени и т. Д.
@Dronz Вы должны принять во внимание, что это было разработано для компьютера за 72000 $ с 9 КБ ОЗУ, который использовал транзисторы и диоды для логических элементов в качестве процессора (никаких микросхем в то время!). Так что не было глупо делать самую основную вещь, которая работала.
@CamiloMartin Я понимаю, почему это было использовано около 1970 года, и для типов, которые когда-либо будут представлять только времена компьютерной системы. К сожалению, это делает эти библиотеки менее полезными для других приложений.
@Dronz Я нахожу понятие «секунды с 1970» достаточно пригодным для использования (сортируемым, простым, легко выполняемым арифметикой и может быть сохранено в int), но когда этого недостаточно, большинство языков имеют лучшую инкапсуляцию для дат и времени , Это все еще широко используется, потому что людям нравится использовать это, но альтернатива всегда за углом.
ОП на мета-уровне верна, схемы, которые мы разрабатываем для времени, всегда были довольно произвольными. Количество дней в году, количество дней в месяце, год "0" и правила для високосного года ... сумасшедшие. Каждая система - это просто серия дурацких компромиссов, потому что это было лучшее, что они могли сделать с доступной технологией и работали достаточно хорошо для их непосредственного использования. Что верно для всех инженерных проектов:)

Matt Howells · Accepted Answer · 2009-07-07T09-55-00.000Z

373

Лучший ответ

Ранние версии измеренного системного времени unix с интервалом 1/60 с. Это означало, что 32-разрядное целое число без знака может представлять только промежуток времени менее 829 дней. По этой причине время, представленное числом 0 (называемое эпохой), должно было быть установлено в самом недавнем прошлом. Как это было в начале 1970-х годов, эпоха была установлена в 1971-1-1.

Позже системное время было изменено на инкремент каждую секунду, что увеличило промежуток времени, который может быть представлен 32-разрядным целым без знака примерно до 136 лет. Поскольку уже не так важно выжимать каждую секунду из прилавка, эпоха округлялась до ближайшего десятилетия, становясь, таким образом, 1970-1-1. Нужно предположить, что это считалось немного более аккуратным, чем 1971-1-1.

Обратите внимание, что 32-разрядное целое число со знаком, использующее 1970-1-1 как свою эпоху, может представлять даты до 2038-1-19, с которой он будет проходить до 1901-12-13 годов.

Matt Howells 07 июль 2009, в 09:55

28

1/60 имеет какое-либо отношение к частоте американской сети?
xtofl 07 июль 2009, в 09:23
54

Это частота одного из генераторов на системных платах, которые использовались в то время. Генератору не нужно было использовать частоту 60 Гц, поскольку он работал на постоянном токе, но, вероятно, было дешево использовать то, что было наиболее распространенным в то время, и тогда телевизоры производились серийно ...
Matt Howells 07 июль 2009, в 10:32
18

На самом деле, в то время было очень часто синхронизировать компьютерные часы и RTC с сигналом сети США, потому что он был (является?) Очень надежным. Это было умножено, чтобы получить часы процессора, и разделено, чтобы получить секунды для RTC.
Alexios 17 июнь 2012, в 21:03
5

@MattHowells - почему они не обновляют эпоху до 2000?
Jedi Knight 17 март 2013, в 09:10
8

@mafioso: Хорошо, я установлю напоминание на своем ноутбуке на 2038 год ... 1901-12-13.
Runemoro 01 апр. 2014, в 03:12
0

@JediKnight - новые языки, такие как Fantom do! Из их класса DateTime : «Время Фантома нормализуется в виде наносекундных тиков с 1 января 2000 года по Гринвичу»
Steve Eynon 29 апр. 2014, в 23:14
18

@JediKnight Это предположение, основанное на моем собственном опыте разработчика: изменение стандарта требует времени, и если ваше изменение не вступит в силу, то вы получите конкурирующие стандарты . Реальное решение проблемы эпохи - это 64-битные целые числа, не сдвигающие эпоху вперед во времени.
Jake 30 янв. 2015, в 19:42
0

@ Matt Howells, не могли бы вы дать мне URL этого официального стандарта, пожалуйста!
neo 08 июнь 2015, в 10:31
0

@JediKnight Не говоря уже о том, что нет особых причин менять время эпохи. Конечно, вы могли бы сэкономить несколько дополнительных байтов, но заметит ли это конечного пользователя или даже не заботится? Кроме того, если вы измените время эпохи, то каждая отдельная программа и библиотека, которые используют временные метки относительно времени 1970 года, должны быть обновлены.
moonman239 14 дек. 2015, в 23:58
0

@JediKnight Или было бы неплохо, если бы это было 0000-1-1 ... за исключением того, что между 1BC и 1AD не было года 0. Или, может быть, время большого взрыва ... за исключением того, что мы знаем только, когда это было до ± 21 миллиона лет, и мы могли бы переполнить несколько целых чисел. Так что, может быть, десятилетие, в течение которого мы разрабатывали компьютеры, в порядке.
James 26 фев. 2016, в 16:36
2

Я ожидаю, что в далеком будущем земляне поверят, что Вселенная была создана 1 января 1970 года 00:00:00.
Jus12 04 март 2016, в 20:09
2

> ...a 32-bit signed integer ...will wrap around to 1901-12-13." Я что-то упустил, не является ли это целочисленным переполнением и, следовательно, технически неопределенным (или, более прагматично, зависимым от платформы)? Год 2038 Проблема в Википедии совпадает с @MattHowells > Times beyond that will "wrap around" and be stored internally as a negative number, which these systems will interpret as having occurred on 13 December 1901 rather than 19 January 2038. обернуты > Times beyond that will "wrap around" and be stored internally as a negative number, which these systems will interpret as having occurred on 13 December 1901 rather than 19 January 2038. Мысли?
Yeow_Meng 20 апр. 2016, в 16:55
1

@JediKnight Почему бы не изменить эпоху на завтра?
Michael 13 июль 2016, в 22:41
0

@Michael Это сломает много существующих систем
Pradeep 29 дек. 2016, в 22:48
0

@ Правильно, но JN спрашивал, почему они не обновляют эпоху до 2000 ... если вы собираетесь обновить и сломать что-то, почему бы не приблизить его к сегодняшнему дню, чтобы, по крайней мере, он длился дольше?
Michael 29 дек. 2016, в 23:03
1

@ Майкл Я думаю, что есть лучшие решения, обновление эпох до 2000 означает, что наши выпускники столкнутся с той же проблемой, я бы предпочел использовать 64-битное time_t и обновить старые 32-битные системы для обработки 64-битного времени, см .: en.wikipedia.org/wiki / Year_2038_problem # Решения
Pradeep 30 дек. 2016, в 01:24
1

Я думаю, что самая большая вещь, которую люди забывают об обновлении, это не только то, что оно представляет «сейчас», но оно хранится в базах данных, файлах и т. Д., И все это должно быть исправлено, это буквально наихудшая возможная идея, кроме ее изменения на письма (шутливо). Вот почему единственный вариант - сделать его неподписанным как хак или, желательно, выделить 64 бита для работы. Это проще изменить, чем редактировать петабайты данных.
simontemplar 02 фев. 2018, в 22:37
0

В комментарии [ stackoverflow.com/questions/1090869/… @ Jörg W Mittag ниже также упоминается год разработки как фактор в решении
harshvchawla 22 авг. 2018, в 04:53
0

Определение эпохи всегда казалось мне правильным, но, поскольку я родился несколько дней в 1970 году, возможно, я предвзят (на несколько дней, очевидно).
Georges 02 март 2019, в 17:54

Показать ещё 17 комментариев