Pull to refresh

Comments 169

Согласен, за эти 18 лет сделают ещё десяток фреймворков и дат баз…
… и напишут еще больше софта, который сломается в 2038.
Использую INT для хранения метки времени на текущий момент. Потом можно будет на BIGINT перейти.
В php уже сейчас нет проблемы на x64 системах c time(), date(), strtotime() и т.п.

UPD: Да, и без знакового INT хватит до 2106-02-07 в моем случае.
Добавил P.S. — дело не в типе хранения данных. С этим всё давно решено и в документации есть предупреждение, что тип TIMESTAMP не хранит даты после 2038го. Дело в функциях конвертации. MySQL просто перестанет понимать 64-битные метки времени из приложения.
Г-н cyclusvitalis имеет ввиду, что хранит в MySQL только метку времени в bigint, и получает в код её же обратно. Конвертацией, пересчетом итд занимается в коде, а не в базе при селекте.
При этом, там не хранится часовой пояс, по это уже другого уровня проблема. Хранить нужно не только часовой пояс, но ещё и город пользователя, ведь часовые пояса могут меняться внутренними законами страны.
Хранить нужно не только часовой пояс, но ещё и город пользователя, ведь часовые пояса могут меняться внутренними законами страны.
А не лучше хранить время по UTC, и конвертировать в локальное при выводе?
UTC хорошо для зафиксированных в прошлом событий. У них, да, есть точное время, и дальше только вопрос его интерпретации.
Но представьте себе задачу: надо рассчитывать логистику, зная, что в Вилларибо смена на складе работает с 16 до 23 по местному, в Саньяго-де-Крус выдача путёвок работает с 10 до 15, а между ними дорога закрывается для грузовиков ежедневно с 11 до 19 из-за размягчения асфальта по жаре, а запасная дорога перегружена.
И таких мест несколько десятков. Вот тут UTC не поможет без местных реалий.

Довольно странно рассуждаете. Вот именно в Вашей ситуации и необходимо учитывать все по UTC без анализа часовых поясов, и только тогда Вам не придётся думать у кого какое локальное время, а расчёт вашей логистики сведётся к анализу доступности маршрутов и рабочих часов каждого из сегментов, поскольку все они приведены к UTC...

> учитывать все по UTC без анализа часовых поясов

У них разные пояса, или времена перехода между летним и зимним временем, а указанные времена всё равно локальные. И что тогда UTC?
Да, на конкретный день вам поможет UTC. Но не для описания общих правил.
UFO landed and left these words here
> The time reference for aviation is defined to be the Coordinated Universal Time (UTC)

1. При чём тут авиация?
>> между ними дорога закрывается для грузовиков ежедневно с 11 до 19 из-за размягчения асфальта по жаре
неужели это было всё про авиацию?

2. По-вашему, все обязаны сдвигать даже времена внутренних рейсов при переходе летнее/зимнее?
Храните количество секунд «от_рождества_христова»? или по другому как-то?
Полагаю, обычное UNIX-время.
Лучше от сотворения мира и пересчитывать в другие летоисчисления отдельно.

Проблема в том, что эта дата тоже неточная.

<sarcasm>Нy подождите, раньше декабря 2037 года заниматься этой проблемой нет никакого смысла.</sarcasm>
Тогда представьте, что вы забронировали авиабилет на 20 января 2038 за год до того, приезжаете в аэропорт, а ваш самолёт улетел 1 января 1970 года.

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

Работаю в данной предметной области, мнение далеко от истины.

Не факт так же, что аналогичная проблема не завалит программу на фортране на пару лет пораньше.
а ваш самолёт улетел 1 января 1970 года.

Скорее в пятницу 13 декабря 1901 года. Там знаковое переполнение, 68 лет вычитаются из 1970-го.

Проблемы с часовыми поясами и поддержкой 32-битных систем.

C 32-битными системами понятно, но что переход с 32-битного int на 64-ный меняет с часовыми поясами?
У нас в PostgreSQL всё в порядке.
SELECT EXTRACT(EPOCH FROM '2038-01-20'::timestamp);--2147558400
Сначала принул второй минус как отрицательное число и хотел уж было воспринять это как сарказм, но потом понял, что это комментарий
я как раз хотел написать что надо использовать «нормальные» СУБД)) в упор не понимаю зачем люди используют «мускуль», если постгрес во всём лучше него :)
И с ЯП та же история — даже Ява отдаёт таймстамп в long (ещё и в миллисекундах, но это важно)
Ну, например, затем, что Wordpress и MediaWiki заточены под MySQL. Нет, конечно, их можно запустить и под PostgreSQL, но это у кого время лишнее.
А жаль.
Мускуль проще настраивается. Сервер поднимается в пару кликов, а с постгресом приходится моск поломать тамошними тулзами и неочевидными правами доступа.
А для мелко-средних проектов возможностей мускуля при этом хватает выше крыши.
Мускуль проще настраивается.
Мой опыт говорит о противоположном, при том что первым я познакомился с постгресом.

моск поломать тамошними тулзами и неочевидными правами доступа
Именно так у меня было с мускулем, в отличии от постгреса, где всё весьма прозрачно.
даже Ява

Вы так говорите, будто от кого-кого, а от Java этого уж никак не ожидаешь.
Не факт, что к 2038 году останутся 32-битные системы…

не факт что и 64-битные будут актуальны:)

Да, да, к тому времени калькулятору будет требоваться больше 16 эксабайт ОЗУ, а boolean будем хранить в 128 битах :)

маркетинг такой маркетинг. когда «наиграются» с частотами и количеством ядер-почему бы не попробовать 128 битную архитектуру?

На данный момент IPv6 внедрён примерно на 30% и продолжает активно внедряться, выбора то нет, IPv4 уже крохи остались.

IPv6 — это хорошо, в европах используется, извлекается профит, но пока VPN-сервисы не предлагают поддержку анонимайзинга через IPv6, а с учётом уже сегодня полностью сломанного internet neutrality, страшного засилья копирастии, цензуры и карательных процедур т.н. "интернет-преступлений" — это очень большой довод в пользу сохранения status quo IPv4.

активно пока только растут цены на v4 блоки

А зачем ее пробовать, если она не дает ощутимых преимуществ, а вносит только кучу головной боли? Переход с 32 битной на 64 был более чем актуальным — ведь в первом случае можно адресовать без костылей до 4 Гб памяти, что сейчас никуда не годится. С помощью 64 битной архитектуры можно адресовать в теории 16 эксабайт, на практике — 256 терабайт, но и это значение огромное даже для долговременной памяти!


Максимум что сделают — добавят больше 128- 256-битных (и даже больше) регистров для векторных операций.

Так речь про маркетинг была)

UFO landed and left these words here
Или на существующих языках наконец-то нормально писать научатся и перестанут вместо оптимизации каждые полгода выкатывать новые «революционные фреймворки» и «убийц С++/Java».

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

Проблема в том, что сложность фреймворков многократно перекрывает любые микрооптимизации компиляторов. Можете скомпилировать классический helloworld С++ и посмотреть сколько кода там будет выполнено, до вызова ядра.
В linux идеальная компиляция должна превращать этот helloworld в write(1, pHello, 14);
модификация GPU в сторону поддержки обычных приложений в операционную систему

Вроде как Windows использует GPU для отрисовки интерфейса с версии Vista.


какой-то язык программирования на это.

Это тоже можно уже давно. Да и все равно это сложно назвать качественным скачком.


Скорее появятся какие-то быстрые, но неточные нейросетевые модули, типа описанных в этой статье.

UFO landed and left these words here

Это не получится сделать — у GPU другая архитектура, оптимальная для большого количества простых вычислений без ветвлений или почти без них. Она хорошо подходит для графики и машинного обучения.


Интерпретатор JavaScript — это линейное исполнение инструкций, где ветвления на каждом шагу. А также работа с вебом, диском. Максимум получится эффективно задействовать несколько потоков, но не десятки и сотни как в GPU. К тому же современные интерпретаторы работают и так шустро.

UFO landed and left these words here
UFO landed and left these words here
Только зачем?
То что можно/нужно выполнять на куче ядер и так уже через всякие OpenCL работает на видухе.
А типичные приложения просто не имеет смысл переносить, потому что в них нет задач для распараллеливания.
UFO landed and left these words here
На практике копирование данных на видеокарту/обратно займет намного больше времени, чем собственно алгоритм. Ну по крайней мере так было лет 5 назад, сейчас не знаю
UFO landed and left these words here

Скорее к обычным RAM плашкам по сопру прикрутят или L7 кэш какой-нибудь на процессор

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


def foo():
a = calculate_a(...)
b = calculate_b(...)
c = calculate_c(...)
# что-то сделать с a, b, c```

сами по себе исполнятся параллельно за счёт огромного конвейра. Всё таки на процессоре не один, не два и не три АЛУ. Даже более того, есть куча SIMD'ов, SSE/SSE2/SSE4.2/MMX, всякие AVX и куча ещё очень интересной логики, которая из поколения в поколение переносится в интересах банальной совместимости, вся эта логика копится, процессор становится очень большим и загрузить действительно на 100% его почти нереально. Как минимум потому что его возможности сильно ограничивают в целях понизить TDP, но это лирика.


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


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


Cyberpunk is coming...

UFO landed and left these words here

Ещё раз) Речь была не про ядры. Для много ядер надо писать специальный код. С синхронизацией и менеджементом.


Здесь речь о конвейризации. Потому что выполнение команды — это один раз взвести нужные транзисторы — это несколько этапов, у некоторых команд с очень сложной логикой. Но когда "часть" команды выполнилась — начальная логика простаивает. Появилась идея начинать выполнять следующую инструкцию ДО того, как текующая выполнилась. За счёт того, что логики на процессоре очень много и почти вся она дублирована (если не сильнее множена) можно упрожнятся в параллельности сколько угодно: можно выполнять одинаковые (независимые) инструкции, можно выполнять совершенно разные (независимые) инструкции на разной логике, можно выполнять зависимые инструкции "внахлёст". Цель — одна — загрузить логику, или, как иногда говорят, конвейр на 100%.


То есть. Ровно то, что вы говорите не просто живёт. Технологии больше 20 лет. И не надо никаких GPU, избыточность логики процессора позволяет вполнять десятки операций одновременно. А умножив на число физических ядер — сотни.


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


Но это ещё не всё. Есть отдельная проблема и связана она с тепловыделением. Оно огромно. И его надо успеть рассеять иначе логика работать не будет правильно. Из-за сверхвысокой интеграции (а некоторые операции имеют созависимую логику, то есть пересекающуюся) получается, что нагружать на 100% конвейр нельзя. Вернее можно, но редко. Причём на какой-то тип операций можно почаще, а на другой просто категорически запрещено.


Да и сложность такого анализа катастрофически сложен. При том, что процессоры уже давно очень сложные, с туевой хучей легаси, заплаток и монструозных инженерных решений.


Но постепенно проблемы решают. Программы становятся типичнее благодаря засилью JS, техпроцесс понижается и ищутся новые материалы, способные к лучшему рассеиванию тепла в том числе, а диссеры всё таки пишутся и какие-то результаты взывают неподдельный интерес. И не нужен никакой GPU, вернее. Нужен, конечно, но в катастрофически специфических задачах. Вернее даже не специфических, а очень, очень простых и типичных с точки зрения именно логики. Практически чистая математика, здесь да. Здесь GPU силён и использовать его можно и нужно. И часто где приходится его использовать. Но опять же, технологии больше 10 лет, предпосылки к ней появились ещё раньше. Всё у биг даты будет хорошо. И с новыми языками тоже)

Держу в курсе: программы, которые работают на GPU (майнеры, перебор паролей и т.д.) компилируют себя (точнее, ту часть, которая должна исполняться на GPU) прямо перед исполнением. Причем делают это достаточно долго. Так что делаем ставку на FPGA блоки в одном кристалле с процессором
для JS нужна архитектура не матричная как у GPU, а ориентированная на аппаратную обработку атрибутных графов. DARPA HIVE в микроисполнении, на десктопе. Собственно, даже под Java и объектные системы до сих пор ничего аппаратного массово нет, одни исследовательские проекты, и мертворожденная ARM Jazelle
Уже с 15 года начали появляться 512 битные регистры в домашних процессорах Intel.

Это специализированные регистры, которые можно использовать только для определенных векторных операций. Но никак не общего назначения — их нельзя использовать для адресации памяти.


Но я и про такие регистры писал:


Максимум что сделают — добавят больше 128- 256-битных (и даже больше) регистров для векторных операций.

256Т — огромное значение для долговременной памяти? Я бы сказал — немного больше потребностей сегодняшнего дня. Немного больше.

Но в таком виде каждая программа всё равно имеет ограниченное адресное пространство. Старые 32-разрядные программы достаточно часто уже упираются в это ограничение.

Да и в целом, работать в 64-разрядном пространстве удобнее. Можно, например, замапить 5-гигабайтный файл на виртуальную память для удобной работы.
И фирменные BSODы от драйверов, которые про PAE не слышали.
> А зачем ее пробовать, если она не дает ощутимых преимуществ, а вносит только кучу головной боли?

64 бита на индекс узла и 64 на адрес памяти внутри узла.
Такой себе NUMA в условиях, когда спрос на мощности растёт, а один узел ускорить нельзя, и в домашнем компьютере 262144 таких узла.
на практике — 256 терабайт, но и это значение огромное даже для долговременной памяти

Почему-то вспомнилась фраза: «640 килобайт должно хватить всем» (с) Билл Гейтс

Я говорил про настоящее время. Сейчас не знаю никого из окружения, кто заполнил бы столько места. К тому же в комменте речь шла скорее об оперативной памяти, а не о долговременной.

Но на AWS вроде как есть инстансы с 24-терабайтной ОЗУ :) Не гига, а именно тера. И именно ОЗУ.

Это специализированное серверное оборудование, обычным пользователям сейчас такое не нужно. Ну и к тому же теоретический предел намного больше (16 эксабайт).

А может не бинарную, как было в СССР?
Так, а вот зачем плюсовать комментарий и при этом минусовать карму, а?
UFO landed and left these words here
ага. и отвечать будет «А сколько вам надо?»
'None' в Python3 уже сейчас 128 бит (16 байт), а bool так и вообще 24/28 байт. Йихуу! =]
И хотя они конечно синглтоны, так что реальная bool-переменная должна стоить нам указателя (8 байт на x64-платформе), а всё одно прикольно. Да и до 16 байт уже всего ничего.

Не факт, что mysql будет актуальным через 18 лет ;)

Я тут вспомнил, что моему сайту 18 лет и он до прошлого года жил на MySQL. И дальше бы жил, если бы это был сайт для дела, а не для души. В прошлом году перевёл его на PostgreSQL. Так что 18 лет не такой уже и большой срок. С тем учётом, что возможностей MySQL/MariaDB многим хватает с головой, может без проблем дожить.

Может и дожить, упакованный в виртуальную машину внутри гипервиртуальной супермашины за шлюзами ipv8 to iv6 и ipv6 to ipv4 :)
Шутка в том, что за 18 лет много чего может поменяться. Много, например, живых баз данных на FoxPro осталось?

Очень много, БЭСТ и Парус до сих пор активно используются, продаются, внедряются, обновляются
Неможко постебусь, но IPv8 через 18 лет — это фантастика. IPv6 был придуман в 1996-ом году. Т.е. уже прошло 23 года, а он ещё не особо шевелится. Так что дай бог, через 18 лет хотя бы 80% компьютеров будут на IPv6 :)

А есть ли вообще какой-то смысл в IPv8? Потому что


Классическое применение IPv6 (по сети /64 на абонента; используется только unicast-адресация) обеспечит возможность использования более 300 млн IP-адресов на каждого жителя Земли.

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

Ну, в темах про IPv6 часто поднимаются вопросы вида — зачем такое сложное придумали. Да и развитие IPv6 идёт странными шагами, вначале решили, что DHCP не нужен, а достаточно SLAAC, потом провайдеры начали по одному адресу выдавать вместо 64-ой сетки. К тому же, когда он проектировался — были совершенно другие практики в работе с сетью.
Т.е., может вообще придумают какой-то аналог Mesh, или что-то типа Tor'а/I2P будет, что приведёт не к просто изменению длины IP, а изменению концепции адресации. В любом случае, гадание на кофейной гуще, у нас сейчас ничего подобного на примете нет.
Легко останутся, к примеру, производственные. Сейчас требование срок работы оборудования — 20 лет. Вывод отсюда следующий — системы, которые будут работать в 38 году УЖЕ произведены и их количество будет только расти (приходит на ум, к примеру, самолеты, вооружения)
Не факт, что к 2038 году останутся 32-битные системы…

Сколько бит у Вояджеров?
image

Восемь или шестнадцать?
UFO landed and left these words here

8-битные контроллеры никуда не денутся. И проблема не в 32 битах, а в том, что их 31, а первый бит знаковый

совсем не так. если иметь ввиду четырехбайтовое целое. то до 2147483647 идет положительное число а далее отрицательное это если десятичное целое.
(и ваш ответ как бы правильный ) однако если мы берем беззнаковое десятичное целое число хранящееся в этих же четырех байтах то… в этом бите знака нет.и ваш ответ как минимум неполный
сможете назвать хотя бы одну массово используемую архитектуру со знаковым битом в целых числах?
Но как же int в шарпе/плюсах под виндой?
А я уверен в том, что еще компы на XP будут встречаться. Крайне редко но будут.
Вчера в бассейне случайно заменил что комп, который турникетом управляет на XP и даже с теплым ламповым LG Flatron
На киви-терминале несколько лет назад видел XP ([хитро съел деньги и ушёл в перезагрузку). Не факт, что их с тех пор обновляли. Ну и для кого-то же MS обновления выпускает.

В прошлом году получили новый биохимический анализатор со встроенным компом на XP. Даже под досом можно купить оборудование, по моему это был один из проточных цитометров Perkin Elmer, разработки начала 90х.

Не факт что к 2038 кто-то будет использовать mySQL :)

Кроме 32-битных систем и баз MySQL есть еще ZIP-файлы, которые точно останутся в большом количестве.
Кроме пользовательских данных, также много исходников ПО хранится в .tar.gz.
А еще ZIP-сжатие используется в куче сторонних программ и форматов.

Ну может наконец то разработчики перейдут на timestamptz и postgresql)
Не понимаю, почему разработчики считают, что это какие-то проблемы в будущем? Сегодня никому не нужно хранить результаты расчётов по пенсионным вкладам и прочим долговременным инвестициям? Никто не допускает мысли, что какое-нибудь оборудование (например, встраиваемое) прослужит 20 лет? В этом году Microsoft на Ignite семинар предлагает про миграцию с Windows 2008 и 2003. Нишевое оборудование 15-летней давности сегодня эксплуатируется повсеместно.

Ограничения платформы, в данном случае MySQL, всем известны и описаны в документации. Все, кому важно хранить даты дальше этого срока используют другие методы. Можно не использовать тип TIMESTAMP и функции FROM_UNIXTIME() и UNIX_TIMESTAMP() и хранить всё в DATETIME (с 1000 до 9999 года), а в unix time преобразовывать на стороне клиента, тем более, операции вроде SELECT '5432-01-20 00:12:34' + INTERVAL 1 YEAR нормально работают. Можно хранить сразу в BIGINT, если это так важно. Всегда есть пути.


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

Полностью согласен, кому нужно те уже давно нашли способ обойти проблему.
Храним в DATETIME. Ничего плохого, оно все равно где-то там внутри как число хранится же вроде
и хранить всё в DATETIME (с 1000 до 9999 года)
Чтобы наступить на те же грабли, только уже в 9999 году? )
только уже в 9999 году

Если читающее сейчас мой комментарий создание в 10 000-м году или позже и использует MariaDB или MySQL, то… да что с вами не так %)?

а вы в какой стране живёте? Мысль продолжать не буду, она про пенсии
Мы должны как можно раньше начать называть это «эпохалипсис».
Лучше всего с 1 января 1970 года.
Проблема в мягком названии. Надо было назвать это «смертельный эпохалипсис метатрон 2038», и все сразу бы обновились.

Апокалипсис будет в количестве версий ОС и СУБД, которые успеют наплодить до 2038.

точный «час/минута/секунда Х» на одном из наших прод серверов:
+---------------------------------------+
| unix_timestamp('2038-01-19 06:14:07') |
+---------------------------------------+
| 2147483647 |
+---------------------------------------+

+---------------------------------------+
| unix_timestamp('2038-01-19 06:14:08') |
+---------------------------------------+
| NULL |
+---------------------------------------+

По заголовку ожидал увидеть статью о 2019-nCoV или об аномальном изменении климата, а тут всего лишь об очередном переполнении unix timestamp.
Кстати, заменив знаковый тип на беззнаковый, можно выиграть ещё ~68 лет, не прибегая к изменению размера поля и конвертации старых записей (при отсутствии необходимости хранения дат ранее 1970 года).
Думаю, что замена на беззнаковый не особо легче чем нормальная переделка под 64 бита. Потому что банально можно делать математику с датами, типа сколько дней между двумя датами. И тут запросто получаются отрицательные числа. Что будет с беззнаковыми и конвертацией туда-сюда, страшно даже представить.
Я настолько старый, что помню как в конце 90-х предупреждали о компьютерном апокалипсисе 2000 года. Проблема была в том, что в куче софта год хранился как две десятичные цифры и после 99-го года неожиданно наступал год 00.
Помнится, была куча идей, костылей вроде (а давайте хранить год в формате «первая, третья, четвёртая цифры»). А вот существенных проблем 1 января 2000 года не припоминаю. Как-то решилось.

Они были, просто не глобальные, с падением самолетов, уходом в разнос ядерных реакторов и вот этим всем.

Ну так ядерные реакторы и диспетчерские уже тогда управлялись компьютерами

Я про это и говорю. Там, где это сильно критично с точки зрения безопасности и больших финансовых потерь, эту проблему решили заранее. А в остальных местах, думаю, решали по мере возникновения.

Так как веб тогда уже был ;-) на большом количестве сайтов дата стала 1 января 19100 года
из-за многочисленных '19' + year в коде (особенно на perl)

А многие писали сайты на перле? :) Ну, я то писал, но думал что это скорее исключение. Еще знал компании, которые веб-игры писали на mod_perl активно.

У меня есть 6 проектов из которых два развиваются на перле, причем там вообще чистый перл даже без фреймворков. Это те 6, что еще приносят клиентам деньги.
Я не в курсе, что это.
Нет, у меня voip-системы.
UFO landed and left these words here

наслаждаюсь сейчас на asp.net core )) а Perl и PHP надеюсь забыть со временем

UFO landed and left these words here
ASP — это васик, PHP — это C, Perl — это ASM. В конце 90-х и начале 2000-х почти все сайты были не перле, PHP еще не был так распространен. На перле не писал, но смотрел исходники. Круто. Но нихрена непонятно.
UFO landed and left these words here
Перл хороший язык. Но вы должны были в универе regexp выучить, а не прогулять.
Вас же никто не заставляет на перле все в одну строчку то писать.
29.02.2000 было больше проблем, чем 01.01.2000. Двухтысячный был високосным, т.к. является исключением из исключения.
Велосипеды отменят?
SELECT DATEDIFF('2038-01-20','2038-01-19') * 86400 + unix_timestamp('2038-01-19') AS ApocalypseDate
Да не будет в 2038-ом никакого MySql


Всё будет в облаках.
Облака могут хоть на святом духе работать — пофиксить проблему даты в них будет легко, поскольку всё централизовано.
и так же централизованно положить все облако из-за криворукого фикса
вообщето проблема будет раньше, ибо в куче систем используется чтото типа
date_add(now(),interval 20 year)

как expire date и другие даты из безконечного будущего.

Так исторически сложилось. :)


На самом деле, StackOverflow отвечает, что в те времена ещё не было unsigned int в C, что весьма неожиданно.


Юниксовое time появилось в ~1971 году, в Unix v1, и возвращало количество 1/60-секундных отрезков с полуночи 1 января 1970 года (man) (хватало только на ~2.5 года), в Unix v6 оно стало вести себя нормально (man).


А потом, в 1978 году, Керниган и Ричи ввели unisgned int. Но уже было поздно.

да вот я и думаю, с одной стороны можно же кодировать отрицательные даты, а с другой не с 1971 же года...

«Апокалипсис грядёт и нам остаётся только молиться… на этих разработчиков.»
А варианта «написать самим и отправить pull-request» нету, что ли?

В статье, вроде, написано, что патч не приняли.

Кстати, да, но и не отклонили — "
We have some concerns how this will interact with our timezone code. And we are also concered about any 32-bit platform support, so it will take some time to evaluate this contribution properly."
Да и патч простенький, можете сами накатить :)
Другой разговор, что бинарную совместимость с базой на диске оно скорее всего поломает :)
И чувак не выпилил все конструкции вида «TODO: remove this when my_time_t is 64 bit compatible» раскиданные в разных местах кода mysql-я. ;)

Некоторое время назад тоже приметил, что проблема 2038 года присутствует в сих функциях, потому просто решил не связываться, ведь можно и самому посчитать количество секунд с начала UNIX-эпохи:


SELECT timestampdiff(SECOND, DATE '1970-01-01', DATE '2038-01-20');
SELECT DATE '1970-01-01' + INTERVAL '2147558400' SECOND;

Если нужна дробная часть, то уже всё далеко не так приятно, но ничего невозможного:


SELECT timestampdiff(SECOND, DATE '1970-01-01', TIMESTAMP '2038-01-20 00:00:00.123090') + microsecond(TIMESTAMP '2038-01-20 00:00:00.123090') / 1000000;
SELECT DATE '1970-01-01' + INTERVAL '2147558400.123090' SECOND_MICROSECOND;

Ещё при необходимости дробной части можно получить количество секунд так:


SELECT datediff(TIMESTAMP '2038-01-20 00:00:00.123090', DATE '1970-01-01') * 86400 + time_to_sec(TIMESTAMP '2038-01-20 00:00:00.123090');

Так дробная часть сохраняет количество знаков.
К сожалению, всё равно нужно указывать datetime дважды.

Иллюстрация идентичности:


> SELECT unix_timestamp(TIMESTAMP '2020-04-04 13:42:42') AS ts;
1586007762
> SELECT timestampdiff(SECOND, DATE '1970-01-01', TIMESTAMP '2020-04-04 13:42:42') AS ts;
1586007762

> SELECT from_unixtime(1586007762) AS dt;
2020-04-04 13:42:42
> SELECT DATE '1970-01-01' + INTERVAL '1586007762' SECOND AS dt;
2020-04-04 13:42:42.000000
> SELECT CAST(DATE '1970-01-01' + INTERVAL '1586007762' SECOND AS DATETIME) AS dt;
2020-04-04 13:42:42

> SELECT unix_timestamp(TIMESTAMP '2020-04-04 13:42:42.123090') AS ts;
1586007762.123090
> SELECT datediff(TIMESTAMP '2020-04-04 13:42:42.123090', DATE '1970-01-01') * 86400 + time_to_sec(TIMESTAMP '2020-04-04 13:42:42.123090') AS ts;
1586007762.123090

> SELECT from_unixtime(1586007762.123090) AS dt;
2020-04-04 13:42:42.123090
> SELECT DATE '1970-01-01' + INTERVAL '1586007762.123090' SECOND_MICROSECOND AS dt;
2020-04-04 13:42:42.123090
В одном моём коде есть кусок, который возможно(!) перестанет работать после 2038. И это… CSS))
Там некий финт с визуальной сортировкой интерфейса, берущий в кач-ве основы для сортировки unix timestamp как css-свойство order. Проблема в том, что в актуальных версиях браузеров тип integer сейчас упирается в 2147483647 и это сейчас не регламентировано никакими спецификациями. Будем надеяться, что за 18 лет, либо W3C всё-таки выкатит какой-то стандарт на эту тему, либо Google и Mozilla самостоятельно расширят диапазон (а они это уже не раз делали).
Ну обычный sint32, ничего необычного.
Сколько нервов было потрачено с этими часовыми поясами и переводом из timestamp в локальное время.
Оказалось:
  1. некоторые фреймворки и языки по разному считают даты.
  2. Оказываются часовые пояса расположены как попало, и у некоторых странах свои законы.
  3. У некоторых стран есть переводы на зимние, летнее время и иногда они передумывают.
  4. Оказалось, что иногда в некоторые месяцы были добавлены и удалены несколько секунд.

И в это ради того, чтобы каждый сонный пролетарий вставал в определённые положение стрелок на часах, чтобы идти на работу.
Подгорело, нужно делать новый стандарт, 64 бит хватит надолго)
Не только MySQL. У нашей OSISoft такая же проблема :) Хотел как всегда убедиться, что у них отсутствует тип boolean, и наткнулся в описалове типов — Timestamp — Any time/date in the range 1-jan-1970 to 1-Jan-2038 Universal Time (UTC).
Смигрировать время на 20 лет назад и на слое извлечения данных из MySQL прибавлять обратно 20 лет :)
Only those users with full accounts are able to leave comments. Log in, please.