Comments 169
При этом, там не хранится часовой пояс, по это уже другого уровня проблема. Хранить нужно не только часовой пояс, но ещё и город пользователя, ведь часовые пояса могут меняться внутренними законами страны.
Хранить нужно не только часовой пояс, но ещё и город пользователя, ведь часовые пояса могут меняться внутренними законами страны.А не лучше хранить время по UTC, и конвертировать в локальное при выводе?
Но представьте себе задачу: надо рассчитывать логистику, зная, что в Вилларибо смена на складе работает с 16 до 23 по местному, в Саньяго-де-Крус выдача путёвок работает с 10 до 15, а между ними дорога закрывается для грузовиков ежедневно с 11 до 19 из-за размягчения асфальта по жаре, а запасная дорога перегружена.
И таких мест несколько десятков. Вот тут UTC не поможет без местных реалий.
Довольно странно рассуждаете. Вот именно в Вашей ситуации и необходимо учитывать все по UTC без анализа часовых поясов, и только тогда Вам не придётся думать у кого какое локальное время, а расчёт вашей логистики сведётся к анализу доступности маршрутов и рабочих часов каждого из сегментов, поскольку все они приведены к UTC...
1. При чём тут авиация?
>> между ними дорога закрывается для грузовиков ежедневно с 11 до 19 из-за размягчения асфальта по жаре
неужели это было всё про авиацию?
2. По-вашему, все обязаны сдвигать даже времена внутренних рейсов при переходе летнее/зимнее?
Теги:… лень
и правда…
Проблемы с часовыми поясами и поддержкой 32-битных систем.
C 32-битными системами понятно, но что переход с 32-битного int на 64-ный меняет с часовыми поясами?
SELECT EXTRACT(EPOCH FROM '2038-01-20'::timestamp);--2147558400
И с ЯП та же история — даже Ява отдаёт таймстамп в long (ещё и в миллисекундах, но это важно)
А жаль.
А для мелко-средних проектов возможностей мускуля при этом хватает выше крыши.
даже Ява
Вы так говорите, будто от кого-кого, а от Java этого уж никак не ожидаешь.
не факт что и 64-битные будут актуальны:)
маркетинг такой маркетинг. когда «наиграются» с частотами и количеством ядер-почему бы не попробовать 128 битную архитектуру?
IPv6 — это хорошо, в европах используется, извлекается профит, но пока VPN-сервисы не предлагают поддержку анонимайзинга через IPv6, а с учётом уже сегодня полностью сломанного internet neutrality, страшного засилья копирастии, цензуры и карательных процедур т.н. "интернет-преступлений" — это очень большой довод в пользу сохранения status quo IPv4.
А зачем ее пробовать, если она не дает ощутимых преимуществ, а вносит только кучу головной боли? Переход с 32 битной на 64 был более чем актуальным — ведь в первом случае можно адресовать без костылей до 4 Гб памяти, что сейчас никуда не годится. С помощью 64 битной архитектуры можно адресовать в теории 16 эксабайт, на практике — 256 терабайт, но и это значение огромное даже для долговременной памяти!
Максимум что сделают — добавят больше 128- 256-битных (и даже больше) регистров для векторных операций.
Так речь про маркетинг была)
Одно не исключает другого, а нормально писать — это не про качественный скачек в архитектуре железа. Да и компиляторы не стоят на месте, а с каждым годом генерируют все более оптимальный код.
В linux идеальная компиляция должна превращать этот helloworld в
write(1, pHello, 14);модификация GPU в сторону поддержки обычных приложений в операционную систему
Вроде как Windows использует GPU для отрисовки интерфейса с версии Vista.
какой-то язык программирования на это.
Это тоже можно уже давно. Да и все равно это сложно назвать качественным скачком.
Скорее появятся какие-то быстрые, но неточные нейросетевые модули, типа описанных в этой статье.
Это не получится сделать — у GPU другая архитектура, оптимальная для большого количества простых вычислений без ветвлений или почти без них. Она хорошо подходит для графики и машинного обучения.
Интерпретатор JavaScript — это линейное исполнение инструкций, где ветвления на каждом шагу. А также работа с вебом, диском. Максимум получится эффективно задействовать несколько потоков, но не десятки и сотни как в GPU. К тому же современные интерпретаторы работают и так шустро.
Design, implementation, and application of GPU-based Java bytecode interpreters
dl.acm.org/doi/10.1145/3360603
То что можно/нужно выполнять на куче ядер и так уже через всякие OpenCL работает на видухе.
А типичные приложения просто не имеет смысл переносить, потому что в них нет задач для распараллеливания.
Это уже очень давно реализовано на 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...
Ещё раз) Речь была не про ядры. Для много ядер надо писать специальный код. С синхронизацией и менеджементом.
Здесь речь о конвейризации. Потому что выполнение команды — это один раз взвести нужные транзисторы — это несколько этапов, у некоторых команд с очень сложной логикой. Но когда "часть" команды выполнилась — начальная логика простаивает. Появилась идея начинать выполнять следующую инструкцию ДО того, как текующая выполнилась. За счёт того, что логики на процессоре очень много и почти вся она дублирована (если не сильнее множена) можно упрожнятся в параллельности сколько угодно: можно выполнять одинаковые (независимые) инструкции, можно выполнять совершенно разные (независимые) инструкции на разной логике, можно выполнять зависимые инструкции "внахлёст". Цель — одна — загрузить логику, или, как иногда говорят, конвейр на 100%.
То есть. Ровно то, что вы говорите не просто живёт. Технологии больше 20 лет. И не надо никаких GPU, избыточность логики процессора позволяет вполнять десятки операций одновременно. А умножив на число физических ядер — сотни.
Можно ли больше? Скорее нет, чем да. Для того, чтобы конвейр работал хорошо операции должны быть в одном контексте или быть принципиально независимым, то есть свободными от контекста (арифметика, например). В рамках одного контекста может появиться, ну, дцать независимых инструкций. Причём они будут разной длины, то есть всё рано конвейр будет простаивать какое-то время. Да по этой теме диссертации пишут с очень забавными моделями программ, чрезвычайно специфические — и всё равно возникают проблемы, а вы хотите случайный код параллелить)
Но это ещё не всё. Есть отдельная проблема и связана она с тепловыделением. Оно огромно. И его надо успеть рассеять иначе логика работать не будет правильно. Из-за сверхвысокой интеграции (а некоторые операции имеют созависимую логику, то есть пересекающуюся) получается, что нагружать на 100% конвейр нельзя. Вернее можно, но редко. Причём на какой-то тип операций можно почаще, а на другой просто категорически запрещено.
Да и сложность такого анализа катастрофически сложен. При том, что процессоры уже давно очень сложные, с туевой хучей легаси, заплаток и монструозных инженерных решений.
Но постепенно проблемы решают. Программы становятся типичнее благодаря засилью JS, техпроцесс понижается и ищутся новые материалы, способные к лучшему рассеиванию тепла в том числе, а диссеры всё таки пишутся и какие-то результаты взывают неподдельный интерес. И не нужен никакой GPU, вернее. Нужен, конечно, но в катастрофически специфических задачах. Вернее даже не специфических, а очень, очень простых и типичных с точки зрения именно логики. Практически чистая математика, здесь да. Здесь GPU силён и использовать его можно и нужно. И часто где приходится его использовать. Но опять же, технологии больше 10 лет, предпосылки к ней появились ещё раньше. Всё у биг даты будет хорошо. И с новыми языками тоже)
Это специализированные регистры, которые можно использовать только для определенных векторных операций. Но никак не общего назначения — их нельзя использовать для адресации памяти.
Но я и про такие регистры писал:
Максимум что сделают — добавят больше 128- 256-битных (и даже больше) регистров для векторных операций.
256Т — огромное значение для долговременной памяти? Я бы сказал — немного больше потребностей сегодняшнего дня. Немного больше.
Да и в целом, работать в 64-разрядном пространстве удобнее. Можно, например, замапить 5-гигабайтный файл на виртуальную память для удобной работы.
64 бита на индекс узла и 64 на адрес памяти внутри узла.
Такой себе NUMA в условиях, когда спрос на мощности растёт, а один узел ускорить нельзя, и в домашнем компьютере 262144 таких узла.
Но дело тут, конечно, не в 64 битной архитектуре.
на практике — 256 терабайт, но и это значение огромное даже для долговременной памяти
Почему-то вспомнилась фраза: «640 килобайт должно хватить всем» (с) Билл Гейтс
И хотя они конечно синглтоны, так что реальная bool-переменная должна стоить нам указателя (8 байт на x64-платформе), а всё одно прикольно. Да и до 16 байт уже всего ничего.
Не факт, что mysql будет актуальным через 18 лет ;)
Я тут вспомнил, что моему сайту 18 лет и он до прошлого года жил на MySQL. И дальше бы жил, если бы это был сайт для дела, а не для души. В прошлом году перевёл его на PostgreSQL. Так что 18 лет не такой уже и большой срок. С тем учётом, что возможностей MySQL/MariaDB многим хватает с головой, может без проблем дожить.
Может и дожить, упакованный в виртуальную машину внутри гипервиртуальной супермашины за шлюзами ipv8 to iv6 и ipv6 to ipv4 :)
Шутка в том, что за 18 лет много чего может поменяться. Много, например, живых баз данных на FoxPro осталось?
А есть ли вообще какой-то смысл в IPv8? Потому что
Классическое применение IPv6 (по сети /64 на абонента; используется только unicast-адресация) обеспечит возможность использования более 300 млн IP-адресов на каждого жителя Земли.
Следующая версия будет актуальна разве что в галактических масштабах, хотя на таких мастабах не будет интернета в его классическом понимании.
Т.е., может вообще придумают какой-то аналог Mesh, или что-то типа Tor'а/I2P будет, что приведёт не к просто изменению длины IP, а изменению концепции адресации. В любом случае, гадание на кофейной гуще, у нас сейчас ничего подобного на примете нет.
Не факт, что к 2038 году останутся 32-битные системы…
Сколько бит у Вояджеров?
Восемь или шестнадцать?
8-битные контроллеры никуда не денутся. И проблема не в 32 битах, а в том, что их 31, а первый бит знаковый
(и ваш ответ как бы правильный ) однако если мы берем беззнаковое десятичное целое число хранящееся в этих же четырех байтах то… в этом бите знака нет.и ваш ответ как минимум неполный
Вчера в бассейне случайно заменил что комп, который турникетом управляет на XP и даже с теплым ламповым LG Flatron
Кроме 32-битных систем и баз MySQL есть еще ZIP-файлы, которые точно останутся в большом количестве.
Кроме пользовательских данных, также много исходников ПО хранится в .tar.gz.
А еще ZIP-сжатие используется в куче сторонних программ и форматов.
Ограничения платформы, в данном случае MySQL, всем известны и описаны в документации. Все, кому важно хранить даты дальше этого срока используют другие методы. Можно не использовать тип TIMESTAMP и функции FROM_UNIXTIME() и UNIX_TIMESTAMP() и хранить всё в DATETIME (с 1000 до 9999 года), а в unix time преобразовывать на стороне клиента, тем более, операции вроде SELECT '5432-01-20 00:12:34' + INTERVAL 1 YEAR нормально работают. Можно хранить сразу в BIGINT, если это так важно. Всегда есть пути.
Это я не к тому, что не нужно исправлять это в MySQL, даже наоборот: как по мне, текущее положение вещей — это позор. Но тем не менее все, кому это нужно, просто используют другие варианты хранения и обработки.
Апокалипсис будет в количестве версий ОС и СУБД, которые успеют наплодить до 2038.
+---------------------------------------+
| unix_timestamp('2038-01-19 06:14:07') |
+---------------------------------------+
| 2147483647 |
+---------------------------------------+
+---------------------------------------+
| unix_timestamp('2038-01-19 06:14:08') |
+---------------------------------------+
| NULL |
+---------------------------------------+
Кстати, заменив знаковый тип на беззнаковый, можно выиграть ещё ~68 лет, не прибегая к изменению размера поля и конвертации старых записей (при отсутствии необходимости хранения дат ранее 1970 года).
Помнится, была куча идей, костылей вроде (а давайте хранить год в формате «первая, третья, четвёртая цифры»). А вот существенных проблем 1 января 2000 года не припоминаю. Как-то решилось.
Они были, просто не глобальные, с падением самолетов, уходом в разнос ядерных реакторов и вот этим всем.
из-за многочисленных '19' + year в коде (особенно на perl)
А многие писали сайты на перле? :) Ну, я то писал, но думал что это скорее исключение. Еще знал компании, которые веб-игры писали на mod_perl активно.
я писал и плакал
SELECT DATEDIFF('2038-01-20','2038-01-19') * 86400 + unix_timestamp('2038-01-19') AS ApocalypseDate
Для начала до 2038 надо дожить :)
Всё будет в облаках.
date_add(now(),interval 20 year)
как expire date и другие даты из безконечного будущего.
а почему оно signed?
Так исторически сложилось. :)
На самом деле, StackOverflow отвечает, что в те времена ещё не было unsigned int в C, что весьма неожиданно.
Юниксовое time появилось в ~1971 году, в Unix v1, и возвращало количество 1/60-секундных отрезков с полуночи 1 января 1970 года (man) (хватало только на ~2.5 года), в Unix v6 оно стало вести себя нормально (man).
А потом, в 1978 году, Керниган и Ричи ввели unisgned int. Но уже было поздно.
А варианта «написать самим и отправить 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."
Да и патч простенький, можете сами накатить :)
Некоторое время назад тоже приметил, что проблема 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Там некий финт с визуальной сортировкой интерфейса, берущий в кач-ве основы для сортировки unix timestamp как css-свойство order. Проблема в том, что в актуальных версиях браузеров тип integer сейчас упирается в 2147483647 и это сейчас не регламентировано никакими спецификациями. Будем надеяться, что за 18 лет, либо W3C всё-таки выкатит какой-то стандарт на эту тему, либо Google и Mozilla самостоятельно расширят диапазон (а они это уже не раз делали).
Оказалось:
- некоторые фреймворки и языки по разному считают даты.
- Оказываются часовые пояса расположены как попало, и у некоторых странах свои законы.
- У некоторых стран есть переводы на зимние, летнее время и иногда они передумывают.
- Оказалось, что иногда в некоторые месяцы были добавлены и удалены несколько секунд.
И в это ради того, чтобы каждый сонный пролетарий вставал в определённые положение стрелок на часах, чтобы идти на работу.
Подгорело, нужно делать новый стандарт, 64 бит хватит надолго)
Апокалипсис грядёт