1. Бывает такое, что дата изменения сбрасывается на текущую после копирования на другой диск или систему, так что просто так не отсортируешь. 2. Бывает, надо отсортировать на чужом компе, а компов куча. Не удобно настраивать на каждом компе под каждой учёткой. Каждой девке операторше показывать, учить, это гемор. Да и не будут они это делать. Проще нажать на столбец с именем, и всё. 3. Файлы могут быть изменены уже после указанной даты в имени папки.
1. Дата создания содержимого? 2. Ну на чужих-то компах юзвери конечно-же папки будут называть так, чтоб тебе потом было удобно сортировать? 3. Сортируешь папки, а не файлы - насрать что там и когда внутри - для этого и ввели сортировку по 100500 вариантам дат и параметров.
"Сделай вот как у меня дома, как мне лично удобно. Мне насрать на других,мне насрать на коллег. Мне насрать на корпоротивный стандарт, международный между прочим!" Нахуй
Как специалист ты должен понимать, что у форматов разные трейдовы. Формат dd/mm/yyyy хотя хуже подходит для хранения бекапов лучше подходит если нужно назвать только день, или только день и месяц. 11/12/2022 -> 11/12 -> 11. Так как год в большинстве случаев понятен из контекста, а часто и месяц тоже, то такой формат удобнее для каждодневного общения, чем постоянно с года начинать. Самая важная информация должна идти вначале, все уточнения - потом.
А с каких пор DD/MM/YYYY подразумевает минуты перед часами? И если уж заговорили об использовании, то в повседневной деятельности данный формат даёт пососать всем остальным. Сортировка данных - понятно, да (хотя компьютер в теории вполне можно было бы и к DD/MM приучить)
А мемес весь изначально в том, что MM/DD - это уёбище, которое ни туда, ни сюда не пристроить.
MM/DD удобно для всяких бухгалтеров которые делают отчётности за год и у них как раз отсортировано по месяцу, а год и так ясен (в этой папочке только нужный год)
Не знаю на счёт китайцев, но программистам удобнее такой формат, и парсить его удобнее, и SQL его нативно понимает, и файлы/логи/папки сортировать: при копировании дата создания у копии может изменяться, в логах же дата последнего изменения тоже может ввести в заблуждение, так что дата в имени файла/папки надёжнее
Как раз программистам пофиг какой формат, время хранится во внутреннем представлении той библиотеки, которой ты распарсил дату-время. И когда тебе нужно передать его в виде строки дальше - просто просишь у библиотеки строку с заданным форматом.
Ну, что за хуйня. В JSON даты - это строки определенного формата, sql приводит к датам строки определенного формата. И там и там в основе лежит yyyy-mm-dd. Это стандарты языков. И ты будешь иметь с этим дело хочешь или нет.
А библиотеку для дат я тебе сам какую хочешь напишу.
Ты блядь ебнулся? Разговор об удобном порядке произношения, я привожу пример исключения в порядке произношения. На меня накидываются и говорят что это исключения, чего? Может вы будете чуток в суть вникать?
Наоборот удобнее. Потому что тебе обычно нужно то, что меняется часто, например, ты можешь забыть, какое сегодня число, а какой год ты вряд ли забудешь.
я много раз пропускал уже оплаченые концерты, ивенты и тд потому что они проходили например третьего февраля а не второго марта и дизайнеры сайтов/афиш/рассылок конченые ублюдки которые нигде не написали буквами месяц явно. стандарт должен быть однозначным и логичным. ставить день посередине между годом и месяцем это конченное уебанство. хуже только имперские размеры ключей потипу 5/6.
Охренеть ты минусов отхватил. Да, ребят, есть международный стандарт ISO 8601, где дата должна быть в виде 2023-01-03. То, что вы все предлагаете - это аналог имперской системы (галлоны, фаренгейты) для времени и даты - то есть ересь.
Там были божественные файлы с замерами. Было чувство, что сидела макака за пультом и меняла формат даты каждые 2-3 замера. Когда спросил, что это за хуйня, мне сказали: «Добро пожаловать в промышленную автоматизацию!».
ещё, товарищи, посмотрите, как вы все* (*некоторые из вас) забиваете на разделители. А ведь разделители тоже часть культуры. богомерзкий mm/dd/yyyy, отечественный dd.mm.yyyy, iso yyyy-mm-dd А вы сами сперва пишете dd/mm/yyyyy или yyyy.mm.dd, а потом бугуртите. Другое дело что некоторые системы пытаются сами распарсить дату по своему усмотрению. Помню как-то скрипт у меня работал работал, а потом начал делать дичь. в mssql вставлялась строка dd/mm/yyyy (да, я тогда на разделители не обращал внимания) и т.к. была вторая половина месяца, то сервер понимал, что 25/07/2002 это середина лета. А через неделю настало 01/08/2002 и это вдруг стало восьмым января.
с дном рождения возникнут неожиданности. это из самого очевидного. а дальше просто возникает вопрос: если всё так однозначно, зачем есть timestamp, datetime, date, time etc.?
2. Бывает, надо отсортировать на чужом компе, а компов куча. Не удобно настраивать на каждом компе под каждой учёткой. Каждой девке операторше показывать, учить, это гемор. Да и не будут они это делать. Проще нажать на столбец с именем, и всё.
3. Файлы могут быть изменены уже после указанной даты в имени папки.
2. Ну на чужих-то компах юзвери конечно-же папки будут называть так, чтоб тебе потом было удобно сортировать?
3. Сортируешь папки, а не файлы - насрать что там и когда внутри - для этого и ввели сортировку по 100500 вариантам дат и параметров.
лучше именовать по годам-месяцам-дням и иметь удобную сортировку по имени/названию
К тому же, ты же не будешь писать 23 минуты 11 часов
И если уж заговорили об использовании, то в повседневной деятельности данный формат даёт пососать всем остальным.
Сортировка данных - понятно, да (хотя компьютер в теории вполне можно было бы и к DD/MM приучить)
А мемес весь изначально в том, что MM/DD - это уёбище, которое ни туда, ни сюда не пристроить.
В JSON даты - это строки определенного формата, sql приводит к датам строки определенного формата. И там и там в основе лежит yyyy-mm-dd. Это стандарты языков. И ты будешь иметь с этим дело хочешь или нет.
А библиотеку для дат я тебе сам какую хочешь напишу.
что за бред!
нам же всем просто и понятно говорить "пять-тристо яблок" чем тристопять яблок!
/sarcasm
что ты там хотел сказать своим "ОДИНнадцать"?
тебе не рассказывали в начальных классах, что 11-19 скорее исключения?
стандарт должен быть однозначным и логичным. ставить день посередине между годом и месяцем это конченное уебанство.
хуже только имперские размеры ключей потипу 5/6.
А если у вас, к примеру, 6-терабайтный фото-архив. То ещё не изобрели более удобного именования файлов, чем YYYY/MM/DD
я пишу через точки
YYYY.MM.DD
хотя бы один вон сверху согласился, что так удобнее
а значит было не зря
Я как-то видел такую херню - HHMMMMDDYYYY
Там были божественные файлы с замерами. Было чувство, что сидела макака за пультом и меняла формат даты каждые 2-3 замера. Когда спросил, что это за хуйня, мне сказали: «Добро пожаловать в промышленную автоматизацию!».
И даты, и длина, и вес
everday DDMMYY
богомерзкий mm/dd/yyyy, отечественный dd.mm.yyyy, iso yyyy-mm-dd
А вы сами сперва пишете dd/mm/yyyyy или yyyy.mm.dd, а потом бугуртите.
Другое дело что некоторые системы пытаются сами распарсить дату по своему усмотрению. Помню как-то скрипт у меня работал работал, а потом начал делать дичь. в mssql вставлялась строка dd/mm/yyyy (да, я тогда на разделители не обращал внимания) и т.к. была вторая половина месяца, то сервер понимал, что 25/07/2002 это середина лета. А через неделю настало 01/08/2002 и это вдруг стало восьмым января.
а дальше просто возникает вопрос: если всё так однозначно, зачем есть timestamp, datetime, date, time etc.?