Релиз новой версии библиотеки glibc 2.29 в США вызвал бурю споров по поводу форматов дат

могущие позволить себе современное железо

Тут человек новую мышку выбирает, с адаптером под „легаси-порт”. Но ты продолжай фантазировать, меня забавляет.

Не зеркаль свои проблемы. Зависть — плохое чувство.

человек новую мышку выбирает, с адаптером под „легаси-порт”

Да флаг в руки, я ему не указываю, что покупать. Это же тебя чем-то USB Type-C не устраивает. У меня все мыши Bluetooth, ему помочь не могу.

Не зеркаль свои проблемы. Зависть — плохое чувство.

Сорян, с питанием у меня проблем нет, да и айфона тоже ибо это шлак для хипсторов. Чему мне завидовать?

У меня тоже нет айфона, ибо не нужен, но могу себе позволить современный ноутбук вместо пятнадцатилетнего 32-бит x86.

Да флаг в руки, я ему не указываю, что покупать.

Скоро основная масса будет с USB-C. А пока пусть запишет на ней url. Карандашом.

Лол.

Это же тебя чем-то USB Type-C не устраивает.

Разумеется не устраивает, как минимум несовместимостью с периферией.

У меня тоже нет айфона, ибо не нужен, но могу себе позволить современный ноутбук вместо пятнадцатилетнего 32-бит x86.

Я тоже могу, и что с того?

Я тоже могу

И живешь на x86_32 с 2Гб памяти? Не верю.

Ну, использовать LC_ALL – радикально. Можно LC_COLLATE оставить в en_US.UTF-8

И живешь на x86_32 с 2Гб памяти?

Во-первых не 2, а 4. А во-вторых — PAE.

Так LC_ALL=C разве не то?

Ну, почти. Но тоже как бы цель не та.

Ну и так, интересное (копипаста с wandbox):

LC_ALL=C.UTF-8 date
Sun Feb  3 19:42:07 JST 2019

И живешь на x86_32 с 2Гб памяти? Не верю.

Я там вообще не про десктоп писал, дурачок.

Я там вообще не про десктоп писал

Последний x86 сервер без AMD64 списан и утилизирован лет десять назад. На какой помойке ты такое старье берешь?

x86 сервер без AMD64

И опять мимо. Да что ж такое?

Во-первых не 2, а 4.

При этом один недоступен из-за особенностей древнего чипсета, а оставшаяся половина памяти зарезервирована ядром. :)

А во-вторых — PAE.

Какие только костыли не выдумают, лишь бы не переходить на 64-бит в 2019 году. :)

И опять мимо.

У тебя там не x86? Или специально не ставишь 64-бит Linux, чтобы жаловаться на 32-бит time_t?

У тебя там не x86? Или специально не ставишь 64-бит Linux, чтобы жаловаться на 32-бит time_t?

Я специально не ставлю 64-бит Linux, потому что Дурной пример заразителен (комментарий)

Я специально не ставлю 64-бит Linux

А, ну ССЗБ, мучайся с Y2038 дальше, чо.

А, ну ССЗБ, мучайся с Y2038 дальше, чо.
Y2038

Юникстаймопроблемы.

При этом один недоступен из-за особенностей древнего чипсета

УМВР.

оставшаяся половина памяти зарезервирована ядром

У тебя ведро резервирует полтора гига? Зачем?

Юникстаймопроблемы.

Нет, всего лишь проблемы Линукса на x86_32 ради поддержки легаси. Поэтому не жалуйся на unixtime из-за своих тараканов.

Нет, всего лишь проблемы Линукса на x86_32 ради поддержки легаси. Поэтому не жалуйся на unixtime из-за своих тараканов.

Отдельные программы, взаимодействуя с ядром, обеспечивают функции системы более высокого уровня. Например, пользовательские компоненты GNU являются важной частью большинства Линукс-систем, включающей в себя наиболее распространённые реализации библиотеки языка Си, популярных оболочек операционной системы, и многих других общих инструментов Unix, которые выполняют многие основные задачи операционной системы.

© педивикия

Что сказать-то хотел? Или не в курсе, что у одной и той же glibc размер time_t на x86_32 — 32 бита, а на других платформах — 64?

Что сказать-то хотел?

Что юникстайм не стандартизирован и ломается в зависимости от архитектуры. Собственно, я это уже давно сказал.

Что юникстайм не стандартизирован

Unixtime стандартизирован в той же мере, что и целочисленные типы в Си.

ломается в зависимости от архитектуры

Нет, в зависимости от реализации и тараканов разработчиков. Архитектура не при чем, никто не мешал Линусу сделать иначе. На том же x86_32 в других системах под time_t отведено 64 бита.

Unixtime стандартизирован в той же мере, что и целочисленные типы в Си.

И из-за этого его поведение на различных платформах различное, что осложняет его использование на практике.

Нет, в зависимости от реализации и тараканов разработчиков.

И это тоже, но в данный момент мы говорим о наиболее популярной реализации.

Архитектура не при чем, никто не мешал Линусу сделать иначе.

Кстати, а как сделано в миниксе? Линус же пилил максимально совместимо с ним.

мы говорим о наиболее популярной реализации.

У наиболее популярной реализации количество секунд хранится в 64 битах.

У наиболее популярной реализации количество секунд хранится в 64 битах.

Это в какой?

Это в какой?

Ты не знаешь самую распространенную ОС? Прям как маленький.

Ты не знаешь самую распространенную ОС?

Windows? Ну ок, в самой популярной реализации в дистрибутивах линукса.

в самой популярной реализации в дистрибутивах линукса.

На подавляющем большинстве установок десктопного и серверного линукса time_t тоже 64 бит.

На подавляющем большинстве установок десктопного и серверного линукса time_t тоже 64 бит.

Но при этом он зависит от архитектуры. Всегда ваш К.О.

Но при этом он зависит от архитектуры.

В других ОС архитектура процессора на размер time_t не влияет, значит дело не в архитектуре, а только в реализации. Плохой из тебя КО.

При этом проблемы с переполнением в 2038 году только у маргиналов и неосиляторов.

В других ОС архитектура процессора на размер time_t не влияет

В линуксе тоже, потому что проблема не в архитектуре процессора, а в архитектуре ОС.

а только в реализации

Какая есть, другой не завезли.

При этом проблемы с переполнением в 2038 году только у маргиналов и неосиляторов.

Верни машину времени обратно Макскому.

И да, различия в реализациях — следствие хренового стандарта.

Кстати, я сталкивался с тем что proftpd для старых файлов (точно старше года) в качестве времени модификации отдавал 00:00 с правильной датой, при этом непосредственно на ФС часы с минутами во времени модификации того же файла отличались и были явно не околонулевыми. С более новыми же файлами такое не проявлялось и время совпадало с временем на ФС. Вангую что это неожиданное проявление той самой „логики” из ls.

s/старше года/старше полугода