Апокалипсис грядёт

    Есть такая проблема — в 2038м году количество секунд с начала эпохи Unix Time перевалит за величину signed int и исчезнет. Это как проблема 2000 года, только намного сложнее, потому что для неё нужно менять типы данных.

    Так вот… в MySQL уже четырнадцать с половиной лет висит просьба починить функции UNIX_TIMESTAMP и FROM_UNIXTIME, которые не могут обрабатывать даты после 19 января 2038го. Это функции конвертации даты в Unixtime и наоборот.

    Проверить это достаточно просто: попробуйте вот этот запрос.

    select unix_timestamp('2038-01-20');

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

    Переходить на MariaDB тоже не вариант: там этот баг уже закрыт как слишком сложный.

    Апокалипсис грядёт и нам остаётся только молиться… на этих разработчиков.

    P.S. Теперь серьёзно: в документации есть предупреждение, что тип TIMESTAMP превращается в тыкву после 2038-го. А вот о функциях конвертации времени никто не предупреждал. Выходит, что все Unix и многие языки программирования уже перешли на 64-битные метки времени, и только функции MySQL перестанут понимать Unixtime безо всякой видимой причины.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 169

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

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

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

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

                      У них разные пояса, или времена перехода между летним и зимним временем, а указанные времена всё равно локальные. И что тогда UTC?
                      Да, на конкретный день вам поможет UTC. Но не для описания общих правил.
                      0
                      Экое безапелляционное заявление…
                      The time reference for aviation is defined to be the Coordinated Universal Time (UTC)
                        +1
                        > The time reference for aviation is defined to be the Coordinated Universal Time (UTC)

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

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

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

                  0
                  Теги:… лень

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

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

                          +9

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

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

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

                              +1
                              ИЧСХ, 13 декабря 1901 таки пятница.
                          +8
                          Проблемы с часовыми поясами и поддержкой 32-битных систем.

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

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

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

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

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

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

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

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

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

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


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

                                                    +2

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

                                                      0

                                                      Маркетинг — штука такая что может заставить всех пересесть на 256 бит, это точно.


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


                                                      или какие-то модули ПЛИС около CPU

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

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

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

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


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

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


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

                                                            0

                                                            я про обычные приложения, перенос логики обычных приложений в GPU.


                                                            вроде скажем интерпретатор JavaScript

                                                              0

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


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

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

                                                                да да, я понимаю что архитектура другая.


                                                                я об этом и говорю: качественный скачок возможен когда кто-то запилит новый язык (возможно при какой-то аппаратной поддержке) в котором люди писать будут так же как сейчас: формулируя тезис-за-тезисом, а исполняться оно будет в параллельной среде на 100500 ядер.


                                                                Вот например все языки программирования так или иначе взяли на борт корутины и поддержку асинхронного программинга.
                                                                (плевать что async/await — кривая реализация этого, пусть и популярная)


                                                                В чём смысл корутин? на них можно писать асинхронный код очень похоже на обычный синхронный. Цель — взять пул наработок за предыдущие годы и перенести эти наработки в новую среду.


                                                                я говорю об аналогичном шаге — но в сторону 100500 ядер теперь

                                                                  0
                                                                  welcome транспьютеры и Оккам-78
                                                                0
                                                                Уже попробовали интерпретатор Java байткода на GPU:
                                                                Design, implementation, and application of GPU-based Java bytecode interpreters
                                                                dl.acm.org/doi/10.1145/3360603
                                                                  –3

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


                                                                  осталось только дойти до чего-то универсального.


                                                                  чтобы можно было брать обычные старые алгоритмы и пускать их, а система сама параллелила бы их на 100500 ядер.


                                                                  Тут или выстрелит новый язык программирования (думаю) или новая (возможно забытая старая) парадигма в старые языки придёт (как вот корутины пришли)

                                                                    +2
                                                                    Только зачем?
                                                                    То что можно/нужно выполнять на куче ядер и так уже через всякие OpenCL работает на видухе.
                                                                    А типичные приложения просто не имеет смысл переносить, потому что в них нет задач для распараллеливания.
                                                                      –5
                                                                      А типичные приложения просто не имеет смысл переносить, потому что в них нет задач для распараллеливания.

                                                                      берём среднестатистический код внутри какого-то там вебсервера.


                                                                      ищем циклы


                                                                      for item in items:
                                                                          # что-то

                                                                      и смотрим, сколько циклов имеют зависимость шага i от шага i-1 и сколько не имеют.
                                                                      Вот все не имеющие зависимости — можно параллелить.


                                                                      берём любую функцию (вообще любой скоуп):


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

                                                                      Если a, b и c вычисляются независимо друг от друга (частое явление), то их вычисление можно параллелить. И так далее.


                                                                      Теоретически можно написать анализатор и параллелить бОльшую часть алгоритмов реального кода.

                                                                        +4
                                                                        На практике копирование данных на видеокарту/обратно займет намного больше времени, чем собственно алгоритм. Ну по крайней мере так было лет 5 назад, сейчас не знаю
                                                                          –2

                                                                          так мы же говорили о том куда развиваться архитектуре.


                                                                          GPU это просто пример модуля умеющего параллельно вычислять.


                                                                          и у GPU при параллельном вычислении куча недостатков: копирование вот Вы вспомнили, отсутствие изолляции и многое другое.


                                                                          но представим себе например GPU встроенный внутрь CPU прямо. То есть разделяющий память вместе с ним.
                                                                          Вот как со-процессор на математику когда-то: 8086/8087. Сперва был отдельно, потом внутрь въехало.


                                                                          я об этом

                                                                            0

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

                                                                          +1

                                                                          Это уже очень давно реализовано на 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...

                                                                            0
                                                                            За счёт этого вот эти ваши

                                                                            да, но нет.


                                                                            я говорю о миграции кода не на 6-10 ядер что есть сегодня
                                                                            а на 600-10000 что есть качественное изменение.


                                                                            переход количества в качество

                                                                              +2

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


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


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


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


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


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


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

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

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


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


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

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

                                                                    0
                                                                    720кб или сколько там?
                                                                    +1
                                                                      +2
                                                                      Но в таком виде каждая программа всё равно имеет ограниченное адресное пространство. Старые 32-разрядные программы достаточно часто уже упираются в это ограничение.

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

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

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

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

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

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

                                                                          0
                                                                          256 терабайт хватит всем!
                                                                            0
                                                                            256 терабайт хватит всем
                                                                            –1
                                                                            А может не бинарную, как было в СССР?
                                                                            –9
                                                                            Так, а вот зачем плюсовать комментарий и при этом минусовать карму, а?
                                                                              +4

                                                                              а ответы в этом калькуляторе вроде 2*2=? будет давать специально обученная нейросеть

                                                                                +2
                                                                                ага. и отвечать будет «А сколько вам надо?»
                                                                                +1
                                                                                'None' в Python3 уже сейчас 128 бит (16 байт), а bool так и вообще 24/28 байт. Йихуу! =]
                                                                                И хотя они конечно синглтоны, так что реальная bool-переменная должна стоить нам указателя (8 байт на x64-платформе), а всё одно прикольно. Да и до 16 байт уже всего ничего.
                                                                                +1

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

                                                                                  0

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

                                                                                    +1

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

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

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


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

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

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

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

                                                                                    Восемь или шестнадцать?
                                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                                      –2

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

                                                                                                                            +1
                                                                                                                            У меня есть 6 проектов из которых два развиваются на перле, причем там вообще чистый перл даже без фреймворков. Это те 6, что еще приносят клиентам деньги.
                                                                                                                              0
                                                                                                                              Комунивер?
                                                                                                                                0
                                                                                                                                Я не в курсе, что это.
                                                                                                                                Нет, у меня voip-системы.
                                                                                                                              0
                                                                                                                              Скорее не сайты целиком, а cgi-bin/*
                                                                                                                                0

                                                                                                                                я писал и плакал

                                                                                                                                  0

                                                                                                                                  а я писал и наслаждался :)

                                                                                                                                    0

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

                                                                                                                                      0

                                                                                                                                      я думаю Вы их просто готовить не научились :)

                                                                                                                                        –1
                                                                                                                                        ASP — это васик, PHP — это C, Perl — это ASM. В конце 90-х и начале 2000-х почти все сайты были не перле, PHP еще не был так распространен. На перле не писал, но смотрел исходники. Круто. Но нихрена непонятно.
                                                                                                                                          +1

                                                                                                                                          непонятно можно писать на любом языке
                                                                                                                                          особенно на Python

                                                                                                                                    0
                                                                                                                                    Перл хороший язык. Но вы должны были в универе regexp выучить, а не прогулять.
                                                                                                                                    Вас же никто не заставляет на перле все в одну строчку то писать.
                                                                                                                                +2
                                                                                                                                29.02.2000 было больше проблем, чем 01.01.2000. Двухтысячный был високосным, т.к. является исключением из исключения.
                                                                                                                                +1
                                                                                                                                Велосипеды отменят?
                                                                                                                                SELECT DATEDIFF('2038-01-20','2038-01-19') * 86400 + unix_timestamp('2038-01-19') AS ApocalypseDate
                                                                                                                                  0

                                                                                                                                  Для начала до 2038 надо дожить :)

                                                                                                                                    +1
                                                                                                                                    Да не будет в 2038-ом никакого MySql


                                                                                                                                    Всё будет в облаках.
                                                                                                                                      +3

                                                                                                                                      а облака будут на MySQL

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

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

                                                                                                                                        а почему оно signed?

                                                                                                                                          +1

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


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


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


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

                                                                                                                                            0

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

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

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

                                                                                                                                              0
                                                                                                                                              Кстати, да, но и не отклонили — "
                                                                                                                                              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."
                                                                                                                                              Да и патч простенький, можете сами накатить :)
                                                                                                                                                0
                                                                                                                                                Другой разговор, что бинарную совместимость с базой на диске оно скорее всего поломает :)
                                                                                                                                                  0
                                                                                                                                                  И чувак не выпилил все конструкции вида «TODO: remove this when my_time_t is 64 bit compatible» раскиданные в разных местах кода mysql-я. ;)
                                                                                                                                                +1

                                                                                                                                                Некоторое время назад тоже приметил, что проблема 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;
                                                                                                                                                  0

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


                                                                                                                                                  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 дважды.

                                                                                                                                                    +1

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


                                                                                                                                                    > 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
                                                                                                                                                    +2
                                                                                                                                                    В одном моём коде есть кусок, который возможно(!) перестанет работать после 2038. И это… CSS))
                                                                                                                                                    Там некий финт с визуальной сортировкой интерфейса, берущий в кач-ве основы для сортировки unix timestamp как css-свойство order. Проблема в том, что в актуальных версиях браузеров тип integer сейчас упирается в 2147483647 и это сейчас не регламентировано никакими спецификациями. Будем надеяться, что за 18 лет, либо W3C всё-таки выкатит какой-то стандарт на эту тему, либо Google и Mozilla самостоятельно расширят диапазон (а они это уже не раз делали).
                                                                                                                                                      0
                                                                                                                                                      Ну обычный sint32, ничего необычного.
                                                                                                                                                      +2
                                                                                                                                                      Сколько нервов было потрачено с этими часовыми поясами и переводом из timestamp в локальное время.
                                                                                                                                                      Оказалось:
                                                                                                                                                      1. некоторые фреймворки и языки по разному считают даты.
                                                                                                                                                      2. Оказываются часовые пояса расположены как попало, и у некоторых странах свои законы.
                                                                                                                                                      3. У некоторых стран есть переводы на зимние, летнее время и иногда они передумывают.
                                                                                                                                                      4. Оказалось, что иногда в некоторые месяцы были добавлены и удалены несколько секунд.

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

                                                                                                                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                                                                          Самое читаемое