Comments 313
Причем в древнем посте по ссылке как раз есть вещи из серии "нифига себе", а вот в этом посте (я в курсе что это перевод) вещи которые не то что программист, наверное каждый окончивший школу и не прогуливавший географию знает. Ну ладно, исключение про часовой сдвиг в 6 минут в Китае, который практически для разработчика бесполезен.
Если бы вы прочитали мой пост, вопросы бы сразу отпали. Эти списки сами по себе — набор утверждений. Куда интереснее, когда к ним приведены контрпримеры и вообще случаи багов, которые могут из-за них возникать.
У нас на географии не рассказывали про особенности мусульманских календарей. Да и переход на зимнее/летнее время казался таким же неизбежным как и Новый год)
про дни недели, и рабочие дни - тут интереснее написано
вот этот ролик, в свое время очень по-радовал https://youtu.be/-5wpm-gesOY
365,25 дня, как это было ранее в юлианском, а 365,2425, на 10 минут 48 минут короче.
Вы хотели сказать 48 секунд.
Заблуждение 1. В сутках 24 часа или 86 400 секунд
Тем не менее в питоне timedelta(days=1) == timedelta(seconds=86400)
Заблуждение о цветах: все русскоговорящие знают слово "фуксия".
Будет ли заблуждением считать, что кто-то где-то в интернете "задротливо" учитывает весь этот ужас и вовремя подправляет в своей библиотеке на ГитХабе?
Прошу прощения, но квантор общности споткнулся на мне.
Есть ли где-нибудь доходчивое описание цветов? А то я не могу представить себе персиковый, мадженту, асфальт и прочие цвета из новояза. Я вообще RGB-цветный (радуга и семь цветов, остальное не назову). Понимаю, что вопрос сложный и у разных народов свои названия (японцы вообще зеленый и синий путают, там даже есть светофоры с синим светом), но все же.
Есть ли где-нибудь доходчивое описание цветов?
доходчивое для кого? Слепого человека, человека, страдающего дальтонизмом или никогда в жизни не видившего ни асфальта, ни персика, ни свинца, ни апельсина, ни граната, ни клюквы итд. - для кого? Привидите пример как вы на пальцах сможете рубиновый цвет описать, который за долго до rgb был известен?
Ну ладно с цветами, а как у вас с чувствами, эмоциями или описаниями с помощью слов - прилагательных? Ведь как вам объяснить значения эмоций - радости, счастья, страдания или горя? Или таких прилагательных как современный, насыщенный, признательный, и миллионы других. Ведь для всего этого нет ни каталога сравнений, да и пощупать значение этих слов невозможно. А особенно всяких новых как - быть в тренде, хайповать, чилить, шазамить, юзать, хейтить, свайпить или описание состояния как криндж или изи.
ни персика, ни свинца, ни апельсина, ни граната
Продавцы жёлтых и белых персиков, красных апельсинов и белых гранатов смотрят на Вас неодобрительно, равно как и "разглядыватели цветов побежалости" на свинце различной степени окисленности.
...хотя и крайности про семь базовых цветов - перебор (ну, хотя бы "салатовый" и "сиреневый" - точно не "новояз")...
Классика же:
Продавцы жёлтых и белых персиков, красных апельсинов и белых гранатов смотрят на Вас неодобрительно..
И что, на них надо равняться? Если кто бананы выведет синим цветом? Тоже возьмём это за основу? Или на общепринятые представления будем ориентироваться?!
Ну например в куче стран используется "таблица наименований цветов по ÆМ". Даже если не все знают что это такое. Подозреваю что и вы с этим в своей жизни сталкивались если где-то видели вот такие карточки:
Я и моё окружение всю жизнь вполне комфортно живёт с цветами, которые знает мужик на первой картинке. Проблемы бывают только когда кто-то начинает выпендриваться как женщина на той-же картинке, но это редкость.
- А почему у вас чёрная смородина такая красная?
- Потому что ещё зелёная!
Эмоции определяются химией мозга.
Уровень счастья определяется дофамином. А его количество можно описать численно.
Можете мне формулу счастья скинуть пожалуйста.
Легко: C17H21NO4
Но что-то как-то на практике сложно.... Это примерно как ботан-биохимик может все объяснить про эндорфин, дофамин, окситоцин, но при походе в бар, все эти знания помогают ему только чтобы потом объяснить, почему девушка не дала (потому что окситоцину мало было). А сельскому балагуру-баянисту все дают, и у всех окситоцин как надо повышается, хотя он это слово даже и не знает.
Возможно, где-то в женском организме происходит необычная хим. реакция и 22см превращаются в C17H21NO4, но не каждый химик способен эту реакцию провести.
Боюсь её нет и никогда не будет. Точнее формулы для достижения счастья.
Намутил. А счастья нету.
Дофаминовые рецепторы с вами не согласны.
Уровень счастья определяется дофамином.
Дофамин, серотонин и окситоцин обиделись такому принижению их роли в человеческом счастье.
Я не биолог, по сему конечно же изложил все грубо и не точно.
Общая же идея такова, что как можно передавать числовое значение цвета в RGB пространстве зная характеристики цветовых рецепторов, так и можно передавать эмоции в N-мерном пространстве химических рецепторов.
Не совсем с вашими словами согласен. Но мне кажется вы увели в другую сторону. Критика первого комментария заключалась в том что мол многим людям неподьёмны современные названия цветов. Типа плиз универсальную систему подавай. А вы приводите как раз реальное положение вещей, что такой универсальной системы нет, и скорее всего и не будет.
Да, непонятны. Когда мне говорят, что цвет асфальтовый, приходится просить показать фотографию. И я не понимаю, чем оранжевый отличается от апельсинового. А эти ваши мадженты, хаки, асфальты и прочее вообще не укладываются в цветовой гамме
Ну я вполне себе могу предположить что вы действительно не можете отличать друг от друга цвета, которые другие спокойно отличают.
Примерно как с музыкальным слухом. У кого-то есть, у кого-то нет.
У кого-то есть тетрахроматия, у кого-то нет.
Я могу отличить один цвет от другого. Я не могу ориентироваться в этих названиях, типа альмандиновый, виардо или там мардоре.
Художники знают и отличают все эти охры жженые потому, что это реальные пигменты и они каждый день ими пользуются.
Одна моя бабушка занималась рукоделием, в частности — вышивала нитками мулине. Она могла посмотреть дома на два близких голубых оттенка, потом прийти в магазин и купить третий — точно между ними. Приходила домой, сравнивала — все точно
Будете много рисовать — научитесь различать десятки оттенков по названиям
Да, непонятны. Когда мне говорят, что цвет асфальтовый, приходится просить показать фотографию. И я не понимаю, чем оранжевый отличается от апельсинового. А эти ваши мадженты, хаки, асфальты и прочее вообще не укладываются в цветовой гамме
Со вторым примером насчёт апельсина могу согласится. Но пример с асфальтом - это какое-то занудство. Вы что асфальт никогда не видели? Конечно видели. те. цвет асфальта можете себе представить, даже если вы его зелёного дерева не можете отличить. То, что у человека могут быть проблемы с цветами и оттенками - это понятно. Но когда такой человек, видя вокруг себя боольшее количество людей, которые с этим не имеют проблем - хочет ставить свой недостаток в основу системы - это что-то новое в науке.
Со вторым примером насчёт апельсина могу согласится.
Для прикола загуглил. Если поставить их рядом, то я разницу вижу. Если показывать мне рэндомно только один, то в жизни не скажу какой из них какой :)
Но пример с асфальтом - это какое-то занудство.
Какой из представленных на картинке "цветов асфальта" - "асфальтовый"?
Напрашивается "все", но ведь это уже тогда не будет какой-то конкретный цвет, да?
Для разговора на бытовом уровне все эти цвета подойдут. Конкретный цвет это например "цвет мокрого асфальта", он же "#505050".
Для разговора на бытовом уровне все эти цвета - серые. Ну, кроме тех, которые скорее чёрные.
Ну это вполне себе может зависеть от окружения.В любом случае не вижу особой проблемы в том чтобы понять что примерно подразумевают когда говорят "цвет асфальта" или там "апельсиновый".
Вот "фуксия" лично для меня проблема. Потому что лично мне уже надо гуглить что это такое :)
Так вопрос-то не в этом, а в том, что наличие отдельного понятия подразумевает наличие отдельного смысла. Асфальтовый - не просто серый, а конкретный серый. Апельсиновый - не просто оранжевый, а конкретный оранжевый, возможно, ещё и с оттенком. И большинство людей этой "конкретики", скорее всего, не знают.
Асфальтовый это какое-то подмножество серого.
"Цвет мокрого асфальта" или "апельсиновый" это конкретный цвет в таблице цветов от какого-то там товарища из Швейцарии.
Ну и да, большинство людей с этой конкретикой сталкиваются только в случае если выбирают цвет в магазине по каким-то там карточкам. Кто-то из них потом использует это и в быту.
Асфальтовый - не просто серый, а конкретный серый. Апельсиновый - не просто оранжевый, а конкретный оранжевый, возможно, ещё и с оттенком.
Да что вы говорите?! Вы вот так с людьми разговариваете? И на белую машине говорите, что она не белая, а #F8F8F8. В нормальной жизни люди используют цвета как ориентировку. Потому что цвет апельсина может варьироваться от спелости и от времени суток и освещения. Абсолютный подход - это просто неправильно. Ухудшает стиль разговора. Не понимаю такой подход.
Да что вы говорите?! Вы вот так с людьми разговариваете?
Это зависит от того в каком контексте вы разговариваете с людьми.
Если вы говорите своей жене "Где мои джинсы асфальтового цвета?", то это один контекст. И точный цвет роли не играет.
Если вы говорите продавцу в магазине "Мне нужна краска с цветом 'мокрый асфальт'", то это другой контекст. И вы имеете ввиду конкретно "#505050".
Отлично. А теперь попытайтесь объяснить это, например, продавцу обоев, что, мол, вам нужны обои цвета асфальта. Сколько рулонов вам придется перебрать?
Не особо много. Потому что во первых продавцы обоев вполне себе понимают что под этим подразумевается. А во вторых потому что обоев в примерно этой цветовой категории не особо много. И это я вам говорю как человек недавно делавший ремонт и искавший серые обои :)
И это я вам говорю как человек недавно делавший ремонт и искавший серые обои :)
..и искавший серые асфальтовые обои :) :) :)
У меня просто картина перед глазами, как на вас продавец смотрел-бы, если-бы вы с этих "козырей" зашли-бы.Боюсь подумать какие у авторов выше-стоящих коментариев ассоциации с коричневым цветом и как они его описывают это продавцам, когда не используют коричневый цвет, а именно как...
и искавший серые асфальтовые обои :) :) :)
Ну словосочетание "мокрый асфальт" вполне себе проскакивало.
У меня просто картина перед глазами, как на вас продавец смотрел-бы, если-бы вы с этих "козырей" зашли-бы
Нормально смотрел бы. По крайней мере у нас это не то чтобы сильная редкость. Более того этот же продавец часто занимается и красками. И у него у самого есть набор табличек с цветами, которые можно намешать. И я готов спорить что среди часто предлагаемых/спрашиваемых оттенков серого "мокрый алфальт" вполне себе встречается.
У меня просто картина перед глазами, как на вас продавец смотрел-бы, если-бы вы с этих "козырей" зашли-бы.
Опытный продавец обоев поймёт даже "заходы" в духе "на полтора тона светлее мокрого асфальта". Потому что они-то как раз по специфике профессии с такими запросами встречаются постоянно.
Конечно, это не означает, что любой продавец обоев будет опытным. Особенно это видно становится если обои подбирать не в специализированных магазинах, а в огромных гипермаркетах направленности "что-то про ремонт", типа OBI или Leroy Merlin.
Надо было как-то обозвать несколько оттенков темно-серого — вот придумали, что один из них будет так называться. К реальному цвету какого то асфальта это название не имеет отношения
Как раз по асфальту я бы и не согласился. Я видел асфальт разных цветов и оттенков (видимо, в зависимости от состава и возраста), от светло-серого и коричневатого до практически черного, а также если поискать "в этих наших интернетах", то можно найти всякую экзотику, типа асфальта велодорожек красного, синего, зеленого и других цветов. Даже если исключить экзотику, то мне, к примеру, совершенно непонятно, какой именно оттенок асфальта следует использовать под обозначением цвета "асфальт". Человек, выросший в городке с серым асфальтом будет считать под этим обозначением знакомый ему цвет, а тот, который вырос в городе с черным асфальтом, будет совсем другой цвет подразумевать.
Всё ещё смешнее. Фокус в том, что асфальт — это природный битум, и именно его цвет называется асфальтовым. Думаю, большинство людей никогда этого материала не видело и никогда не увидит.
Самое же популярное дорожное покрытие, которое видели примерно все, правильно называется "асфальтобетон"...
А когда вам говорят, что цвет коричневый, просите показать корицу?
Обидчивые какие...
Либо RGB, либо радуга и семь цветов. Фиолетовый цвет радуги непредставим в RGB. Вместо него рисуется лиловый.
По сути вопроса: набрав в яндексе название цвета, увидите его в ответе. С точностью до возможностей и калибровки вашего монитора.
Давайте будем пунктуальны: фиолетовый цвет непредставим в sRGB gamut, а сама размерность цветового пространства не имеет к этому никакого отношения.
Так и есть. Я, вроде, ничего другого не писал.
Так-то, фиолетовый цвет радуги вполне себе представим в модели RGB, только не в цветовом пространстве sRGB.
Модель RGB так называется, потому что состоит из красного, зелёного и синего цветов. Никак их синтезом невозможно получить фиолетовый, находящийся за синим.
В глазу стандартного человека всего три вида цветовых рецепторов. Относительное значение частоты/длины волны спектрального цвета тут ни при чём, имеют значения лишь величины откликов.
Ну так фиолетовый цвет - это такой, который не формирует значительного отклика в красном рецепторе.
Хотя там сложные кривые отклика на самом деле.
Ну да, так и есть. Поэтому фиолетовому соответствует много синего и немного красного.
Это лиловый. В фиолетовом нет красного.
Если фиолетовая длина волны действует на 'красные' колбочки - то есть.
Давайте не подменять понятия. Нет никаких “красных” колбочек. Есть три вида рецепторов со сложной спектральной характеристикой (которые, кстати, обрабатываются четырьмя каналами в мозгу). Фиолетовая длина волны, допустим, действует, на “красные” колбочки, но не действует на “зелёные” колбочки, на которые действует красная длина волны.
В общем-то мне не очень понятно, почему приходится спорить по визуально совершенно очевидному (в буквальном смысле) факту, что натуральный фиолетовый цвет не соответствует никакому из отображаемых монитором.
иолетовая длина волны, допустим, действует, на “красные” колбочки, но не действует на “зелёные” колбочки
Там все волны действуют на все колбочки: у них очень сильно перекрываются спектры поглощения. Только отклик разный по интенсивности.
И если «натуральный» фиолетовый цвет вызывает отклик в «красной» колбочке 0,5, в «зелёной» 0.1, в «синей» 0,5. То и светодиодики в мониторе, которые смогут вызвать такойже отклик вызовут тоже ощущение цвета. Хотя да, формально спектр — совсем другой.
Но видеть фиолетовый цвет на (очень хорошем) мониторе вы будете так же как в реальности.
Другое дело — цветовое пространство RGB — оно действительно убого просто по построению, но это не в прямую яркости светодиодиков в мониторе. Лучше Lab какой-нибудь или что-то ещё более специализированное.
Да не смогут светодиодики в мониторе вызвать такой же отклик, как натуральный фиолетовый цвет, потому что он не является их линейной комбинацией в базисе откликов рецепторов.
Объясняю эффект на пальцах: допустим, каждый из светодиодов R, G и B вызывает отклик в красном (или, к примеру, зелёном) рецепторе глаза, а фиолетовый цвет не вызывает. Может такое быть математически? Да запросто.
Цвета R, G и B не ортогональны друг другу в математическом смысле. Их просто выбрали, как простой способ покрыть достаточно большое цветовое пространство.
Объясняю эффект на пальцах: допустим, каждый из светодиодов R, G и B вызывает отклик в красном (или, к примеру, зелёном) рецепторе глаза, а фиолетовый цвет не вызывает. Может такое быть математически? Да запросто.Ну так наверное умные дяди могут так выбрать светодиодики, чтоб такого математически не было?
Модель RGB состоит из "красного", "зеленого" и "синего" стимулов, преимущественно воздействующие на L, M, S-чувствительные колбочки сетчатки. А цвет - это ощущение человека, возникающее в его голове, в том числе в результате воздействия на колбочки. Если человек может видеть какой-то цвет, то его можно воспроизвести соответствующими стимулами. И RGB модель для этого прекрасно подходит.
Спектр тут ну практически совсем ни при чем.
В первой части вы правы. Но проблема в том, что светодиоды R, G и B имеют совсем не такие спектры излучения, как стимулы L, M, S. Поэтому во второй части вы неправы, нельзя с помощью RGB взвесить любой стимул, который может получить глаз.
Да что мы спорим, у вас квалиа цветов-то есть, наверное? Неужели на глаз не заметно, что в RGB далеко не все видимые цвета?
Что уж там фиолетовый, даже монохроматический лазерный зелёный на экране не передать. Ни в смысле спектра, ни в смысле ощущения.
Но проблема в том, что светодиоды R, G и B имеют совсем не такие спектры излучения, как стимулы L, M, S.
Это проблемы светодиодов, а не цветового пространства.
Идеальные R, G и B являются монохроматическими, и тот монохроматический лазерный зелёный — это как раз G.
Из идеальных монохроматических излучений вы получите интерференционную картину, а не смешение цветов. Поэтому аддитивная модель не может быть монохроматической.
Нет, для этого нужен CMYKOGV. V и есть фиолетовый.
KOGV используются в печати, т.к. реальных красителей CMY недостаточно и для расширения цветового охвата. Немного странно объяснять аддитивную RGB в терминах производной от нее субстрактивной CMY.
Немного странно объяснять аддитивную RGB в терминах производной от нее субстрактивной CMYНе просто странно — физически невозможно и не нужно
Nikon в своё время выпускал матрицы для фотоаппаратов с аддитивной матрицей CMYG. У меня был такой, Coolpix 5700. Субтрактивность к цветам CMY гвоздями не прибита.
*монохроматический фиолетовый.
фиолетовый цвет непредставим в sRGB gamutВ данном случае — RGBэто не конкретный цветовой профиль — а абсрактный способ кодирования цвета, на основе чувствительности клеток сетчатки. Интуитивно он не очень понятен, зато легко согласуется в физиологией
Фиолетовый цвет радуги непредставим в RGBА розовый непредставим в радуге :)
Скорее всего такого подробного описания нет, так же как и нет константы на базовые цвета, которых ещё относительно недавно насчитывали не семь, а пять. Ну и плюс много завязано на среде, в которой человек рос: к примеру чукчи могут различать около пятидесяти оттенков белого снега, а типичный житель средней полосы нет.
к примеру чукчи могут различать около пятидесяти оттенков белого снега, а типичный житель средней полосы нетРазличать могут все — глаза у всех одинаковые. Каждый скажет — этот темнее, этот чуть холоднее и так далее. Но назвать их, по отдельности — не могут, просто потому что нет практики
Глаза тоже бывают разные, см. Дальтонизм. И мозг разный - в смысле, опыт. По автомобилям такое можно сказать - там, где рядовой водитель (или покупатель) не увидит разницы в окраске, опытный маляр или подборщик скажет: о, да тут дверь крашеная.
Я могу точно сказать, чем проба отличается от оттиска и какой краски печатнику надо прибавить убавить на прессконтроле. Тоже опыт, глаза как у всех
А пример с маляром прямо говорит — что дело в опыте, а не глазах
А вот кстати не факт. Может так оказаться, что люди с глазами "не той системы" на маляра выучиться не могут, потому что не видят разницы в оттенках.
Если отклонений нет — то в норме, человек способен видеть и различать оттенки. Просто некоторые натренированы, потому что сначала учились в техникуме или как это сейчас называется, а потом долго работали. А другие «пришли с улицы» и сильно отстают от первых
Я ни за что не скажу, какой из цветов как называется, но могу точно определить, что «сюда немного мадженты надо добавить», что звучит абсолютной дикостью для человека с художественным образованием, например
"Человек в принципе способен" и "Человек способен сделать это прямо сейчас" - не очень тождественные понятия. Я вот, например, в принципе способен управлять самолётом. Но не очень натренирован, и самолёт уроню, если меня сейчас в кресло пилота посадить.
Зрение тоже не полностью от рождения доступно, различать объекты приходится учиться. Я вот, к примеру, не способен различать иероглифы. Понятное дело, я их отличу если дать две крупные картинки и полчаса на игру "найти 10 отличий", но вот просто посмотрев на них — ни за что не скажу одинаковые они или разные. Почему с цветами не может быть так же?
Я сегодня так обсмеялся утверждению, что знание языка и грамматики это инстинкт, что исчерпал ресурс на шутки
Но вы все равно не совсем правы.
Глаза устроены по одному приципу, потому как он записан в ДНК.
А вот реальные органические глаза довольно сильно различаются даже в пределах одной черепушки, хотя выглядят, при отсутствии совсем уж критичных патологий, одинаково.
А как быть например с людьми у которых разное "цветовое восприятие" у разных глаз? Начиная от того что картинка у одного глаза "теплее". И кончая действительно тем что смотря на один и тот же предмет разными глазами люди видят разные цвета?
То есть если что-то не вписывается в вашу личную картину мира, то это можно просто игнорировать? Ну ок...
Вы делаете это не настолько ярко и задорно, как Аста, когда он безапелляционно заявляет, к примеру, что знания языка и грамматики — это инстинкты
Ну ок
Самый адовый набор цветных карандашей — это жалкие 500 оттенков. Нет никаких сложностей, чтобы отличить их один от другого. Базовых пигментов, которые используются в живописи — всего несколько десятков. Остальное многообразие — получается смешением их с белилами или сажей, иногда друг с другом
Другое дело — какие-то очень узко специфичные вещи, типа профессионального теста на цветокоррекцию, когда выдают набор бумажек, которые неподготовленному человеку кажутся вообще одинаковыми, все сразу. А в живописи все совсем не так трагично — заучить полсотни наименований и соответствующий цвет — не требует каких-то сверхьестестенных глаз.
А в живописи все совсем не так трагично — заучить полсотни наименований и соответствующий цвет
Мне кажется, в этой дискуссии не различаются "отличить" в смысле 'вот рядом лежат и видно, что они не совпадают' и "отличить" в смысле 'увидеть цвет и сразу правильно его назвать'.
Я вот сильно не уверен, что без длительной тренировки можно добиться второго. Точно так же, как без достаточно длительной тренировки нельзя научиться сразу называть услышанную ноту -- хотя их тоже не так уж и много.
О том же самом — эти оттенки способен различить любой человек, а для точного названия каждого в отдельности — надо тренироваться. Я как раз с этого и начал
Хм. Пожалуй, нужен еще один случай. Промежуточный между этими двумя.
Когда тебе показывают цвет, убирают, ждут достаточное время, показывают тот же или слегка отличающийся и спрашивают 'тот же цвет был?'.
Есть подозрение, что количество цветов, который человек может различить во всех этих трех случаях - несколько не одно и то же без специальных тренировок.
Зачем пытаться придумывать сложное, если есть и простые правила, как обвести человеческое восприятие вокруг пальца. Наши глаза не сенсоры, которые воспринимают цвет как что-то абсолютное. Окружающие предметы, подсветка или как в этом случае ассоциация в нашей голове, что темные поля всегда темнее светлых - обманывают нас при интерпритации цветов. А вы - показать/спрятать/спросить итд.
На мониторе с DCI-P3 каджит видит сплошь дубликаты и несколько тройничков.
Если вместо неравномерных мазков будут однородные точки, то вся палитра вообще сократится до десятка (или меньше) цветов.
Различать могут все — глаза у всех одинаковые
С одной стороны принцип устройства глаз у всех одинаковый, но с другой количество клеток в сетчатки глаза, отвечающих за цветовосприятие, может варьироваться от человека к человеку. Вот и получаем что есть среднестатистическое цветовосприятие, но далеко не все могут видеть отличия в определенных оттенках даже без патологий зрения (дальтонизма).
Я вообще RGB-цветный (радуга и семь цветов, остальное не назову)
с учётом того, что физически в радуге бесконечно цветов, а конечное число цветов - как количество цветов, так и конкретные цвета в её составе - имеют языковую природу (то есть в разных языках у радуги может быть разное число цветов, и даже если число совпадает - то, например, это могут быть не те же самые цвета, а, например, наши синий и зелёный там будут считаться одним цветом)... Ох, даже с радугой всё непросто, что уж про время-то говорить...
Маджента — это как раз вполне себе RGB-цвет, красный с синим.
По юлианскому календарю продолжают жить монастыри горы Афон. Иногда происходил обратный процесс: с григорианского календаря страна переходила обратно на юлианский, создавая месяцы длиннее 30 дней. К примеру, Литовская губерния в 1800 году после 11 января вернулась в 1 января. Сможет ли любая система корректно сказать, в какой день недели родился человек из той эпохи?
Бессмысленный вопрос. Это разные календари, и путаница может быть только когда время выводится текстом, т.к. нет практики указывать, какой календарь используется. Проблема же с программой cal в том, что она зачем-то решила вывести 2 календаря одновременно, совершенно от балды выбрав день, когда заканчивается один и начинается другой.
Стараешься не вникать в счет времени пока тебя это не коснется в работе. Но тогда уже как правило поздно (прошу прощения за каламбур).
To же самое с представлением чисел с плавающей точкой в компьютере. Ты знаешь, что там есть свои особенности, но не вникаешь в них пока тебя это не коснется в работе.
Спасибо за материал!
Россия перешла на григорианский календарь в 1918 году с прыжком в 13 днейНе вся, РПЦ до сих пор не перешла. Рождество в России отмечается 25 декабря по юлианскому календарю, по григорианскому это 7 января следующего года.
Заблуждение 3. В месяце 30 днейЭто заблуждения тех, кто в школе не учился?
Заблуждение 8: Часовых поясов не больше 24
Это заблуждения тех, кто в школе не учился?
Ну я вот тоже так думал. Я потом наткнулся в одном проекте, что месяц принимался за 30.5 дней. В биллинге, блин. Конечно же, нафига в биллинге точность выше чем плюс-минус день?.. И эта погань там проросла везде, как же я в своё время задолбался это вычищать. И ведь написал это сеньорный сеньор.
У сеньера были свои счёты со временем.
В биллинге, блин.У Мегафона есть тарифы, в которых плата за интернет списывается раз в 28 дней, то есть 13 раз за год. Вот он прогрессивный взгляд на время =)
Я как то это объяснял девочке в салоне Мегафона. Она утверждала, что "платить раз в 4 недели очень удобно!". Я возражал, что зарплату почему то платят по другому графику - немного реже.
Вот он прогрессивный взгляд на время =)
Здесь дело не совсем во времени, просто тарифный план в Мегафоне придумывали те же люди, у которых в пакете молока 900 мл, а в упаковке яиц 9 штук.
Я бешусь, что Scaleway не пишет помесячные цены за свои виртуалки, а пишет вроде 0.0001/час. Причем за диск, IP адрес и прочие неотъемлимые вещи - отдельно еще. Так что, фиг посчитаешь, сколько тебе выйдет в месяц. А если даже посчитаешь и посчитаешь правильно - не будет уверенности, что точно правильно посчитал.
И в биллинг захожу, у меня за скромненьку VPS снимается то 2.20, то 2.27. Думаю, что за чертовщина! А потом понял, что это же 30-31 день. Отчасти логично - день - штука достаточно объективная, а вот месяц - то 28, то 31.
Надеюсь, для честности, високосную секунду включать в счет не будут....
С меня билайн за 2 минуты межгорода снял 20 руб 29коп. Девочка в техподдержке на голубом глазу объясняла, что несмотря на то, что в прайсе написано 10р14коп то, что они внутри вычисляют все с точностью до 4 знаков после запятой приводит к нечетной сумме при умножении на 2.
(не, я догадываюсь, что эти умники со времен УЕ не поменяли софт, а зафиксировали курс и 10.14 это не 10.14, а сколько-то уе умноженное на курс и округленное до двух знаков, но тем не менее… Оно же в прайсе в РФ. Нельзя было целое число копеек в цену поставить?)
Я бешусь, что Scaleway не пишет помесячные цены за свои виртуалки, а пишет вроде 0.0001/час.Ээээээ…
Если они не поменяли интерфейс от того, который я помню — там есть здоровенный переключатель «час-месяц». Дернешь его — и все сразу понятно. Калькулятор там тоже все правильно считает и раскладывает отдельно каждый айпишник и любой другой параметр, суммируя сколько будет, можно поиграться галочками и прикинуть — надо оно тебе или нет за такие деньги
Может я чего не вижу? Вот мне интересны позиции Dev1-s и Startdust1-s.
Вот прайс: https://www.scaleway.com/en/pricing/ , огромный переключатель вроде есть.
Если переключиться в раздел Compute - то там будут dev/stardust, но с почасовой ценой, а переключалки уже нет. В разделе All я их не вижу. По фильтрам если выбирать, они есть, но показывается только часовая. Попробуйте сами, как у вас будет?
Просто такой специфический хостинг.
У Selectel'а было раньше облако с посекундной тарификацией. Насколько помню процессора и памяти (а вот диска — операциям ввода и отдельно размерам).
у AWS и сейчас нечто подобное только цены еще и от региона зависят, трафик — откуда и куда и так далее.
В некоторых случаях это удобно притом что калькулятор на сайте есть но в некоторых — хочется вот что попробще...
Оказалось что на 10 годах ошибка в месяц, на сотне в три ( считал с 1900 по 2000 ).
Я решил поиграть с коэффициентами и пришел к такой формуле:
func GetAverageMonthsBetween(start, end time.Time) int {
return int(float64(end.Sub(start).Hours()) / (24.0 * 30.4298))
}
При этом даже на 100 годах все ок, но если брать еще больший диапазон то числа все равно расходятся с правильными.
Я разумеется выбросил этот код и сделал по-человечески, однако прежде я погуглил и что бы вы думали по запросу «difference between two dates in months golang» выводит как раз решения в стиле
fmt.Printf("months: %f\n", diff.Hours() / 24 / 30)
Короче один написал и даже не протестировал, другой взял чужой кусок кода…
Эм, а разве нельзя умножить разницу в годах на 12 и прибавить разницу в номере месяца? Даты-то уже есть, значит в них есть год и месяц.
Если РПЦ протянет до 2101го, будет интересно посмотреть, что они будут делать и когда будут праздновать своё Рождество начиная с этого года!
Это заблуждения тех, кто в школе не учился?Имеется в виду, что программист при написании кода может делать неявные предположения о предметной области. А проще говоря — элементарно «не подумал», не обработал ситуацию.
Говоря об исключениях для конкретных применений, стоит вспомнить телепрограмму, где граница суток - это 6 утра, а не полночь
Хотелось бы видеть подобное исключение для голосовых помощников. Или хотя бы уточнение.
А то попросишь, например, Алису в 0:02 поставить будильник на завтра - получишь не то, чего хотел
Точно, есть такое. Приходилось работать с такими данными, там время так и указывалось, например, "27:13:45". Для удобства переводил в обычный вид. Только почему-то запомнилось, что не 6 утра, а сутки с 5 часов до 29 часов.
Вроде как на ЖД раньше был какой-то нюанс с началом суток. Был случай у меня, как-то давно родственники должны были приехать ночью, как раз в период этого "нюанса". В результате они приехали на 1 день раньше, пришлось им "под дверью" сидеть.
Это скорее всего либо московское/местное время, либо момент сезонного перевода часов. Либо поезда, ходящие через день (по четным и нечетным числам) и соответственно стык 31 и 1 числа месяца.
Вроде с ЖД это все и началось. Что такое полдень - это понятно и легко установить по тени от палочки или колокольни. Но в каждом городе свой полдень, по чуть-чуть отличается. И важно как-то планировать, чтобы время было единым на всей дороге, а то поезд, который в 00:00 по одному времени столкнется с поездом, который там же в 00:10 но по другому времени. В итоге, время на ЖД вроде починили, зато полдни поломали....
Всех деталей не помню, но что-то типа метеорологические полночи идут через 3 часа — типа три соседних часовых пояса как бы склеивается в один.
Да, с этим сразу сталкиваешься, если попытаться самостоятельно агрегировать данные с метеостанции, например получить среднюю или минимальную температуру (и сверить с какими-то другими результатами).
Немного подробностей есть тут: http://pogodaiklimat.ru/faq.php
Она не мифическая. Я как-то беседовал с синоптиками - у них многое до сих пор на Фортране крутится, потому что написано огромное множество кода, и переписать всё это плюс проверить на отсутствие багов (а могут быть такие, которые с первого взгляда не видно, но результаты оно исказит) - банально нет денег.
Такое происходит довольно часто.
Скажем, на одном из проектов где я участвовал, границей суток считалось 8 утра по Московскому времени — именно с 8 до 8 формировались все суточные отчёты.
А прямо сейчас на проекте есть подсчёт числа незакрытых вчерашних заказов, и что-то мне подсказывает что однажды заказчик тоже попросит границу суток передвинуть.
Ещё, как я слышал, в розничной торговле "кассовые сутки" заканчиваются с окончанием смены — то есть где-то в 10-11 часов по местному времени (а ещё если касса закрывается вручную — сутки выходят переменной длины).
Хранить-то можно. Проблемы возникают при взаимодействии с внешним миром. Который хочет даты в человекопонятном формате. И в своей таймзоне заодно.
Типовое хранение GMT + TZ в среднем удобнее с учетом необходимости взаимодействия с людьми.
Удобнее как раз хранить в Unix time, т.е. в количестве секунд от 1970 года. А вот людям уже выдавать как нормально отформатированую дату в их календаре с их часовым поясом.
timestamp вызывает у программистов непреодолимое желание обращаться с ним неправильно. Например, прибавить 3600 и думать что это будет через час. Или еще море подобных неверных штук.
Если ваш язык позволяет напрочь запретить так делать я рад. Типовые языки увы так не позволяют. А на ревью все такое отслеживать муторно и черевато пропусками.
Значит используем подходящий тип данных, который своим видом и своими свойствами заставит программистов правильно с ним обращаться и не совершать таких глупых ошибок.
прибавить 3600 и думать
Именно тут какие подводные камни кроме високосных секунд? Которые и так идут вне равномерности юниксайма и прочих tzdata? Это ведь будет действительно через час, различия могут быть только при форматировании времени (т.е с учётом конкретной tz), нет?
А попробуйте прибавить к timestamp уже не час, а месяц. Я чуть выше писал про месяц в 30.5 дней. Такая срань как раз и возникла, потому что дата в timestamp хранилась.
Все-таки час — это вполне однозначная мера промежутка, а вот месяц — плавающее значение. Естественно, если к числу прибавляем UNKNOWN то получим UNKNOWN.
Час превращается в любую другую величину при доработке через какое-то время. Не надо зацикливаться именно на нем. Я про идею почему timestamp плох.
Все-таки час — это вполне однозначная мера промежутка
Вы статью-то читали? Перевод часов выпавший на ваш час превратит его в иинтервал отличный от 3600 секунд.
Вы не путайте промежуток и две отсечки на шкале времени. Час определяется, как 3600 секунд. Чего не скажешь о месяце, который то 30, то 31, а то и вовсе 28 или 29 дней.
Пользовательские сценарии и алгоритмы их обработки бывают разными.
Сценарий «поставь будильник через час» реализованный через сложение секунд в таймстемпах и поставку крона на получившееся время в момент перевода часов может дать интересный результат.
Такие мелочи важны. Именно они дают пользователям радость или ненависть ко всем этим вашим технологиям.
Сценарий «поставь будильник через час» реализованный через сложение секунд в таймстемпах и поставку крона на получившееся время в момент перевода часов может дать интересный результат.
Берём текущий таймстамп, прибавляем к нему 3600, переводим в локальное время. Если за этот час будет перевод часов, то и локальное время мы получим уже с коррекцией. В результате будильник разбудит нас ровно через час, как заказывали.
Если говорим «поставь будильник на 02:30», а этого момента не будет, (01:59:59 -> 03:00:00) то попытка перевести указанное время в таймстамп должна выдавать ошибку и потребуется разъяснение пользователя, что же именно он имел в виду.
Хорошая теория. А теперь я покажу код. Talk is cheap. Show me the code.
Java 17, самый современный способ работы со временем в Джаве. Язык на котором пишут бизнес логику. Никаких проблем.
Timestamp timestamp1 = new Timestamp(1667095200000L-2*3600*1000L+ 100000);
LocalDateTime localDateTime1 = LocalDateTime.ofInstant(timestamp1.toInstant(), ZoneId.of("Europe/London"));
System.out.println(localDateTime1);
Timestamp timestamp2 = new Timestamp(timestamp1.getTime() + 3600*1000L - 10000);
LocalDateTime localDateTime2 = LocalDateTime.ofInstant(timestamp2.toInstant(), ZoneId.of("Europe/London"));
System.out.println(localDateTime2);
Ой
2022-10-30T01:01:40
2022-10-30T01:01:30А вот так на правильных типах:
Timestamp timestampNormal = new Timestamp(1667095200000L-2*3600*1000L + 100000 - 10000);
LocalDateTime localDateTimeNormal = LocalDateTime.ofInstant(timestampNormal.toInstant(), ZoneId.of("Europe/London"));
System.out.println(localDateTimeNormal);
LocalDateTime localDateTimeNormal2 = localDateTimeNormal.plusHours(1).minusMinutes(1);
System.out.println(localDateTimeNormal2);
Вроде получше
2022-10-30T01:01:30
2022-10-30T02:00:30С правильностью второго поведения можно спорить, но первое точно неверное. У вас вся логика основанная на "случится после" отработает неверно. Допустим клинер уже прошедших событий удалит запись о будильнике.
Если речь о голосовом помощнике, то ему нет смысла переводить таймстамп обратно в дату. То есть, для него «через час» — когда таймстамп будет равен текущему плюс 3600 секунд. А если попросить его поставить будильник на 2022-10-30T01:30:00, то он, по хорошему, должен уточнить, какие именно 01:30 имеются в виду, первые или вторые и соответственно выставить таймстамп будильника.
Если надо выставить время в кроне, то однозначного решения для локального времени всё равно нет. Событие, выставленное на интервал перевода времени на час назад отработает дважды. Выставленное на интервал перевода времени на час вперёд не отработает ни раза.
https://man7.org/linux/man-pages/man2/clock_gettime.2.html
Технически, каждый хост живёт в некотором своем текущем времени. В линуксах есть уже почти десяток констант, сильно меняющих представление о нем, в зависимости от вопроса. 3600 это 3600 секунд, а что такое через час и во сколько это будет - уже вопросы консенсуса. Причем часто ответа в рамках хоста не достаточно - нужен глобальный консенсус (в рамках всей вашей системы).
Именно тут какие подводные камни кроме високосных секунд?
Перевод часов? Прибавили к 1:30:00 час, получили 2:30:00, а оно не наступило, потому что после 1:59:59 сразу идёт 3:00:00.
Прибавили 3600, получили 1269732600.
Перевели в локальное время, получили 2010-03-28T03:30:00MSK (GMT+04:00).
Никаких проблем.
Проблема в том, что не указано, какое именно 'через час' хотелось. То, которое 'по прошествии указанного количество времени' или то, которое 'циферблат часов должен показывать на единицу часов больше'.
Вот если нам нужно было было второе - то расчет неправильный. Потому что 2:30 действительно не наступило и этого события не было.
Ну, при переводе часов unixtime не меняется же, он идёт дальше как и шел равномерно и прямолинейно. Через час (=60 минут, и 60*60 секунд) при любых переводах часов и обнаружении себя в любой точке мира будет +3600 к текущему значению unixtime без вариантов. Где там не наступило 2:30 это вопрос исключительно локального времени, в конкретной tz, о чём я и написал ..
Где там не наступило 2:30 это вопрос исключительно локального времени
Да, но люди-то с локальным временем работают.
Вот например у человека самолёт в 6 утра. И, чтобы успеть, ему надо выйти из дома в 2:30, т.е. за 3.5 часа до рейса. А про перевод времени он забыл. Он в 0:30 просит Алису напомнить ему о необходимости выхода из дома в 2:30, вы это обрабатываете как timestamp (закономерно посчитав, что 2:30 будет через 7200 секунд после 0:30), и... во сколько сработает уведомление и успеет ли человек на самолёт?
Ещё интереснее, боюсь, может получиться с будильником на 2:30 - он сработает через сутки после необходимого, когда 2:30 наконец наступит.
Я не уверен, что тут в принципе возможна хорошая универсальная обработка.
Тут явное нарушение: или говоришь что сделать, или как, но не оба сразу.
В данном случае задача выйти из дома за 3.5 часа до рейса, а не выйти из дома в 2:30.
задача выйти из дома за 3.5 часа до рейса, а не выйти из дома в 2:30.
Для пользователя в 99% случаев (вернее, в 363/365) эти задачи идентичны, и проговаривать "поставь уведомление за 3.5 часа до 6:00" он не будет, потому что может посчитать это в уме (а время рейса Алиса может не знать). И проблем с обработкой не будет, что характерно. А вот два дня в году эта схема даст сбой, и именно в таких случаях нужно правильно обработать ситуацию, чтобы помочь человеку успеть на самолёт.
Ваше решение покрывает только случай перевода стрелок вперед, в случае перевода назад будет два 2:30, это раз.
Аэропорт может находиться физически рядом, но в другом часовом поясе или часовой пояс может смениться для аэропорта иначе, чем для путешественника, это два.
Оба этих случая ваше решение не покрывает, в то время как правильная формулировка покрывает не только эти случаи.
правильная формулировка покрывает не только эти случаи.
Проблема в том, что голосовые помощники создаются не строго для тех, кто может формулировать точные ТЗ с учётом редких факторов, а для рядовых пользователей. И именно поэтому они должны уметь отрабатывать ситуации, которые пользователь может забыть или упустить - они же в конце концов позиционируются как помощники, а не как тупые исполнители.
Поэтому отработка события, установленного пользователем на 2:30, может (если мы хотим помочь человеку, а не как-формально выполнить команду) быть, в зависимости от задачи, выполнена в 1:30 (если это напоминание о самолёте), в 3:30 (если он в 0:30 поставил таймер, чтобы мясо готовилось 120 минут) или не выполнена вообще (редкий случай - нам, скажем, нужна ночная фотография часов на Спасской башне со стрелками на 2:30).
они же в конце концов позиционируются как помощники, а не как тупые исполнители
именно поэтому надо быстро, решительно забыть про императивные формулировки.
выполнена в 1:30 (если это напоминание о самолёте), в 3:30 (если он в 0:30 поставил таймер, чтобы мясо готовилось 120 минут
Так помощник или гадалка? )
Ни одна из этих задач не должна быть выполнена таким образом.
Так помощник или гадалка?
Помощники - живые, по крайней мере - умеют переспрашивать, если задача в текущей формулировке может быть выполнена не так, как ожидает отдающий команду. Проблема в том, что для ожиданий нужен интеллект, а не тупое следование формальным правилам.
Но мысль, которую я хочу донести, не меняется: в одном случае решение "прибавить 7200 к текущему таймштампу" позволит получить результат, нужный пользователю, а в другом - всплывёт подводный камень в виде опоздания на самолёт (и, опционально - в виде орущего на весь дом помощника следующей ночью).
Вы одновременно наделяете помощник сверхинтеллектом, предполагая, что он способен задавать уточняющие вопросы до полного выяснения задачи, тут же превращаетет его в тупого исполнителя, формулируя задачу императивно.
При этом совершенно игнорируете тот факт, что императивно сформулированная задача не требует уточнений.
Помощнику нужно сформулировать задачу и снабдить достаточным набором информации для её решения — и все.
Для того, чтобы выключить мясо через два часа не нужно ставить будильник, нужно ставить таймер.
Чтобы успеть к самолету — не нужно выйти ровно за 3,5 часа до вылета, а нужно учесть массу факторов: от очереди на регистрацию/досмотр и пробок до ЖД-станции под аэропортом и смены часовых поясов.
При этом желание пользователя, раз он пользуется помощником, — исключить человеческий фактор, а императивная формулировка прямо ограничивает снизу пространство для ошибок — человеческим фактором, к которому вы еще предлагаете добавить неопределенность в виде угадайки.
Для того, чтобы выключить мясо через два часа не нужно ставить будильник, нужно ставить таймер.
Что ставит пользователь и что делает программа - не обязательно одно и то же. Если пользователь поставил таймер на два часа - под капотом там вполне может быть "озвучить уведомление в [нынешний таймштамп плюс 7200]". И тут у нас всё корректно, уведомление сработает вовремя.
к которому вы еще предлагаете добавить неопределенность в виде угадайки
Нет. Я предлагаю переспросить, если возможна неопределенность или неверное исполнение.
Когда пользователь просит озвучить уведомление сегодня в 2:30, а оно не случится из-за перевода часов - вот тут надо уточнить у него, что он имеет в виду, а не искать ближайшие 2:30 (следующие сутки), не считать разницу между нынешним 0:30 и абстрактным 2:30 (7200, уведомление сработает в 3:30) и не озвучивать уведомление в 3:00 со словами "уведомляю с опозданием на полчаса, в 2:30 не получилось по техническим причинам", и не промолчать, потому что уведомить в 2:30 сегодня технически невозможно.
А как, во-вашему, должна быть обработана императивная команда "озвучить уведомление сегодня в 2:30", если после 1:59:59 сразу наступит 3:00:00?
Если пользователь поставил таймер на два часа — под капотом там вполне может быть "озвучить уведомление в [нынешний таймштамп плюс 7200]"
Так это одно и то же =)
Более того, именно этот вариант и должен использоваться: мясу и духовке все равно на отображение даты, а ошибка чревата или горячее — сырым! или суп, который ты варил, дожарился и высох в угли.
Я предлагаю переспросить, если возможна неопределенность или неверное исполнение
И что можно неверно исполнить в абсолютно корректном императиве установи уведомление сегодня на 2:30? Время корректное, дата и действие тоже.
а оно не случится из-за перевода часов
Ага, так бывает, если вместо решения задачи сперва страдать фигней, доказывая машине кто здесь хозяин, а потом требовать от нее манкипатчинга с телепатией.
озвучивать уведомление в 3:00 со словами "уведомляю с опозданием на полчаса, в 2:30 не получилось по техническим причинам"
Кстати, это будет с опережением
А как, во-вашему, должна быть обработана императивная команда
Она вообще не должна возникнуть в рассматриваемом случае.
Есть задача, задача перемещения тушки к условленному моменту в определенное место. ВСЁ. Не надо показывать, кто тут круче и делать за машину ее работу (через одо место и даже не на половину) — у нее мозги железные, она пусть и считает.
И что можно неверно исполнить в абсолютно корректном императиве установи уведомление сегодня на 2:30? Время корректное, дата и действие тоже.
В том и проблема, что раз в год это сочетание даты и времени будет некорректным. В смысле - что времени 2:30 в этих сутках нет. Так во сколько должно звучать уведомление после корректного императива?
Кстати, это будет с опережением
Это зависит от задачи. В случае с аэропортом - с опозданием, в случае с мясом - с опережением.
Она вообще не должна возникнуть в рассматриваемом случае.
Повторюсь - проблема в том, что голосовые помощники создаются не строго для тех, кто может формулировать точные ТЗ с учётом редких факторов, а для рядовых пользователей. Пользователь по каким-то своим соображениям попросил уведомить его в 2:30. Он забыл, что 2:30 в этих сутках нет, потому что ситуация эта - редкая. Помощник в этой ситуации должен помочь пользователю. А подумать, как обработать некорректное сочетание даты и времени, должен программист этого помощника - а не надеяться, что таймштамп с тупым прибавлением секунд может обработать любую ситуацию.
У вас, простите, какой-то айтишный снобизм, что рядовой пользователь должен быть умнее машины, а машина должна тупо исполнять команды. Но это время закончилось довольно давно - и сейчас пользователем может быть трехлетний ребенок, домохозяйка или слесарь пенсионного возраста (при всём моём уважении к слесарям - с IT у них порой не очень хорошо), у которых в принципе нет опыта общения с программами, зато есть красивая колонка, которая умеет понимать голос и выполнять команды. И если техподдержка на претензию "Почему уведомление на 2:30 не сработало и я опоздал в аэропорт" ответит из той же колонки (потому что по-другому наш слесарь не умеет) не "извините, наш помощник туповат, но мы учтём и исправим, вот вам промокод", а "не надо показывать, кто тут круче" - высока вероятность, что колонка полетит в стену, подписки не будет, плюс соседи по гаражам точно никогда эту штуку не купят, послушав эту историю.
В том и проблема, что раз в год это сочетание даты и времени будет некорректным
Этого нельзя утверждать без контретного TZ, а он не указан.
Чтобы знать TZ надо иметь актуальные базы и геопозицию.
Что приводит нас опять к тому, что надо не умничать самому, а отдать расчеты машине.
проблема в том, что голосовые помощники создаются не строго для тех, кто может формулировать точные ТЗ с учётом редких факторов, а для рядовых пользователей
И-мен-но!
И надо решать задачу пользователя, а не пытаться угадать почему же занавески синие, тем более — не перекладывать на пользователя работу машины, и уж подавно — не усложнять задачу, заранее сделав неправильно часть работы машины за машину.
Задача пользователя — попасть на посадку вовремя. Если известно, что формальности занимают от одного до двух часов — значит задача сводится к доставке тушки в аэропорт в известной локации к известному времени. Человеку надо какое-то время, чтобы собраться — значит, надоминание должно прозвучать за некоторое время до отправки.
Итого задача, которая должна быть поставлена перед ассистентом: напомни мне за полчаса до выхода, что скоро пора — а потом еще за пятнадцать и пять минут.
И эта задача для тех для рядовых пользователей — звучит гораздо естественнее и формируется в любом состоянии не требуя никаких расчетов.
Вы это игнорируете, заставляя рядовых пользователей считать с риском ошибиться, но виноват вам в этом каджит, и снобизм, вдруг, у каджита.
При этом практически все ваши аргументы либо повторяют типичные ошибки айтишного снобизма, включая перечисленные в посте, и лично вами, либо просто требуют невозможного.
Но виноват каджит, ага.
Вы это игнорируете, заставляя рядовых пользователей считать с риском ошибиться
Я никого не заставляю считать. Я говорю, что люди могут - по по ошибке, по задумчивости, по неумению давать однозначные формулировки - поставить задачу так, что машина не сможет её решить. И эти случаи нужно обрабатывать, если вы пишите программу для людей, которые прекрасно разбираются в слесарном деле, но голосовой помощник для них - чудо чудесное, к которому нет талмуда на восемьсот страниц "Как правильно формулировать команды". Вы, кстати, так и не ответили на вопрос. Как, во-вашему, должна быть обработана императивная команда голосовому помощнику "озвучить уведомление сегодня в 2:30", если после 1:59:59 сразу наступит 3:00:00? Человек отдал именно такую команду. Что делаем?
Я никого не заставляю считать
У вас человек из людей, которые прекрасно разбираются в слесарном деле, но голосовой помощник для них — чудо чудесное высчитывает время.
Это значит, что вы уже заставили его считать. Вместо того, чтобы просто озвучить свою задачу.
Как, во-вашему, должна быть обработана императивная команда голосовому помощнику "озвучить уведомление сегодня в 2:30", если после 1:59:59 сразу наступит 3:00:00?
Ответ на этот вопрос был дан несколько раз. Он не изменился.
Пользователю нужна другая задача, и именно задачу пользователя надо решить.
И вы беретесь за решение задачи пользователя не с того конца вообще.
Человек отдал именно такую команду. Что делаем?
Люди и команду Алисе выпить йаду отдавали, и заигрывали. И что?
К решению этого вопроса отношения ни то, ни другое, ни третье не имеют.
Озвученная вами задача — успеть на самолет, ее и надо решать. А вместо решения задачи пользователя вы занимаетесь демагогией..
Я так и не понял что вы хотите от пользователя? Он вам не расскажет всю свою историю и все свои планы, а если и расскажет вы не поймете. Пользователь просто простит поставить будильник на 2:30, которых не сущесвует.
Чтобы успешно продавать помощников надо уметь такие задачи решать хорошо.
От пользователя?
Ничего сверхестественно, просто чтобы он сказхал словами через рот когда и где ему надо быть. Это же не сложно?
А вычислениями должна заниматься машина, они для этого предназначены и делают это гораздо лучше мясных мешков.
У него же билет есть, в нем все написано: название аэропорта, время вылета. У ассистента есть текущая геопозиция и средства для построения маршрутов — на этом необходимый и достаточный набор данных в принципе заканчивается.
Этому решительно непонятно, почему вообще данная задача должна намеренно решаться через казуистику.
Ничего сверхестественно, просто чтобы он сказхал словами через рот когда и где ему надо быть. Это же не сложно?
Это настолько сложно что можно считать нерешаемой задачей.
Пользователь скажет что он хочет, а не что вам надо. Попытка заставить пользователя говорить что вам надо приведет к тому что вы ни одного помощника не продадите.
У него же билет есть, в нем все написано: название аэропорта, время вылета.
У него есть, а у вас нет. И надо с этим работать.
У ассистента есть текущая геопозиция и средства для построения маршрутов — на этом необходимый и достаточный набор данных в принципе заканчивается.
Вы не знаете как пользователь хочет ехать и какие у него планы. Может он три часа по дьютифри ходить собирается? Или у него такие чемоданы что он через любые пробки поедет только на такси. И вы не знаете что там в аэропорту. Может очередное обострение и надо приежать за 5 часов? Не пытайте сделать то что невозможно сделать. Просто поставьте будильник на указанное время или уточните что именно хочет пользователь если время неоднозначно. Эта задача проще и ее точно можно решить.
Ну, если словами через рот — задача не решаемая, то каджиту стоит умыть руки.
Однако, никаких примеров нерешаемого вы не привели.
Пользователь скажет что он хочет
Так это и требуется. Без пересчетов, умничания и попыток создать себе на ровном месте проблем.
У него есть, а у вас нет. И надо с этим работать
У каджита и не должно быть, и работать с этим каджит и не должен.
И вообще, может, этот что-то пропустил, но, вроде бы, нигде не было озвучено, что билет не был куплен не через ассистента.
Может он три часа по дьютифри ходить собирается?
Но он-то об этом знает и сказать может?
Потому что если нет, то проблема глубже серьезнее и вообще в другой области лежит.
Или у него такие чемоданы что он через любые пробки поедет только на такси.
То же самое.
И не знаете что там в аэропорту. Может очередное обострение и надо приежать за 5 часов?
Каджиту об этом знать и не надо. Более того, это форс-мажор, его невозможно учесть.
Но! Об этом, учитывая что билеты берутся сильно заранее, как правило, может знать ассистент — если аэропорт предоставляет данные, конечно. И тогда тем более надо не выделываться, а поручить работу машины — машине.
Ассистенты гугла и яндекса уже давно умеют сообщать о событиях, прокладывать маршруты и заказывать такси, разве нет?
Просто поставьте будильник на указанное время или уточните что именно хочет пользователь если время неоднозначно.
Да, это то, к чем пытался подменить свою же задачу оппонент.
Задача, между тем, все еще вовремя добраться до аэропорта, а не проверить, валидно ли желаемое время…
Вы хотите сделать живого секретаря и у вас это не получится по объективным причинам. Значит вы не сделаете ничего. Продукта нет, рынка нет, денег нет.
При этом я сделаю нормальное решение с которым пользователь может взаимодействовать и не расстраиваться. У меня есть продукт, рынок и деньги.
Вроде очевидно что лучше? Если жить не в мире розовых пони, а в реальном мире.
Эммм…
Во-первых, нормальное решение, если этот термин вообще применим, — это не заставлять пользователя делать то, что машина делает лучше.
Во-вторых, цифровой ассистент в представлении konst90, которое можно составить из его аргументов, то ИР с телепатией, навыками нихерового психолога и чуть ли не магией по Кларку — то непроходимый тупица, так что на предложенной шкале можно выбирать любую удобную точку отсчета.
В-третьих: этот опирается на существующие технологии. GPS, заказ билетов онлайн, прокладка маршрутов с выбором предпочитаемых средств — это все было доступно еще дюжину лет назад на любом смартфоне.
Еще раз: этот говрит о том, что задача поставлена одна — а решается совсем другая, да еще с претензией на универсальность. О чем каджит тоже сказал и показал узкие места.
Вместо анализа этих узких мест вы вдвоем, блять, доёбываетесь, простите за плохой французский, на основании того, что вам хочется видеть чтобы не слышать оппонента.
Ну, если словами через рот — задача не решаемая, то каджиту стоит умыть руки.
Классический пример:
Каджит перестал пить коньяк по утрам? Да или нет?
Пожалуйста, озвучьте словами через рот. Это же ведь так просто, да?
Это значит, что вы уже заставили его считать.
Нет. У него дома появился голосовой помощник без инструкции - какие команды ему давать можно, а какие нельзя. Он и даёт команды, голосом. Конкретно в этот день он дал команду - "Алиса, поставь уведомление на 2:30". Где-то в инструкции к Алисе написано, что так делать нельзя? Я не видел.
Ещё раз: условие задачи - человек, который поставил уведомление на 2:30. А не человек, про которого программе достоверно известно, что у него самолёт в 6:00. И программисту надо отработать задачу "Человек поставил уведомление на 2:30". Варианты отработки - на самом деле это 3:30, на самом деле это 1:30, переносим на следующие сутки, переспрашиваем человека, [вписать своё].
Пользователю нужна другая задача
То есть - голосовой помощник должен сказать: пользователь, тебе нужна другая задача, эту я выполнить не могу. Согласны? А для этого простой арифметики с timestamp недостаточно. Нужно ещё проверять само наличие указанного пользователем времени, как минимум.
Каджит вам ссылку на ваш же коммент дал, где вы описывали совершенно другую задачу, которую вы пытаетесь безальтернативно решить наиболее проблемным путем.
И этот вам который коммент говорит, что через такую жопу решать данную задачу вообще не нужно, она решается проще, и, главное, без мыслительных усилий со стороны человека, а вы спорите словно сам с собой.
UPD:
голосовой помощник должен сказать
Это его возможностей по анализу сильно зависит.
она решается проще, и, главное, без мыслительных усилий со стороны человека
То есть, мыслительные усилия на то, чтобы сформулировать задачу в терминах "что я хочу в принципе", а не "что я хочу конкретно от помощника", не считаются? А на то, чтобы вообще догадаться, что помощнику нужен полный контекст, а не только задача, которую ожидают конкретно от него? А на то, чтобы понять, какой контекст здесь считается полным (а то некоторые могут и полчаса рассказывать, что им на самом деле нужно)?
где вы описывали совершенно другую задачу
Идём по ссылке и читаем задачу:
Он в 0:30 просит Алису напомнить ему о необходимости выхода из дома в 2:30
Вот это и есть та задача, которую попросил решить пользователь: напоминание в 2:30. Решайте эту задачу, а не рассказывайте пользователю, что он дурак и делает что-то через жопу. Потому что иначе он сочтёт, что он действительно дурак и недостоин пользоваться вашим гениальным изобретением, и вы останетесь без клиента.
она решается проще
Серьёзно? Человек пенсионного возраста без опыта в IT может сделать две вещи. Первое - посчитать в уме (чем он всю жизнь занимался) "так, до гаража полчаса, до дочки пятнадцать минут, в аэропорт ехать столько-то, запас времени такой-то", получить 3.5 часа, вычесть их из шесть утра, получить 2:30 (ошибся старый человек, забыл про перевод времени, бывает) и попросить поставить уведомление на это время. Вы так и не придумали, как обработать эту довольно простую просьбу.
Либо - вам нужно обработать фразу "Алиса, мне нужно быть в аэропорте в 6 утра, а перед этим дойти до гаража по адресу такому-то, потом заехать по адресу такому-то и оттуда в аэропорт". Удачи вам научить нейросеть это кушать и объяснить человеку, что говорить надо именно так и нигде не ошибиться. Это ведь проще, чем проверить в календаре наличие сочетания даты и времени.
Он в 0:30 просит Алису напомнить ему о необходимости выхода из дома в 2:30
Да? Смотрим:
Вот например у человека самолёт в 6 утра. И, чтобы успеть, ему надо выйти из дома в 2:30, т.е. за 3.5 часа до рейса. А про перевод времени он забыл. Он в 0:30 просит Алису напомнить ему о необходимости выхода из дома в 2:30, вы это обрабатываете как timestamp (закономерно посчитав, что 2:30 будет через 7200 секунд после 0:30), и… во сколько сработает уведомление и успеет ли человек на самолёт?
Выделены:
жирным — задача человека
курсивом — Джон Генри
UPD: Иначе получается, что на самолет человеку не надо, и выделенная криво сделанная наполовину подзадача не имеет смысла.
Да?
Да. Человек попросил голосового помощника уведомить его в 2:30 утра. Слесарь пенсионного возраста купил колонку и сказал: "Алиса, завтра в 2:30 утра скажи мне, что пора ехать в аэропорт".
Завтра перевод времени, и после 1:59 наступит 3:00. Вы разработчик интерфейса колонки. Обрабатывайте. Что колонка должна озвучить и когда?
Постарайтесь ответить на вопрос (выделен жирным), а не растекаться по древу о том, что человек тупой и ему нужна другая задача.
P.S. Задача человека - не "Самолёт в 6 утра", а "Попасть в соседний город", раз уж вы за него решаете.
Да.
То есть, в аэропорт ему не надо. Ну ок, чо.
Следовательно, все ваши последовавшие за тем комментом аргументы множатся на ноль.
Бывает, да.
А откуда человек знает, что колонка должна знать, что ему надо в аэропорт?
Оттуда же, вероятно, откуда колонка должна угадать на самолет ли надо человеку или фото часов Спасской башни сделать.
А она должна угадывать или уточнить?
Согласно автору перла выходит, что применять эвристики. Т.е. угадывать.
Честно говоря, не вижу там этого "применять эвристики". Не затруднит процитировать?
Весь второй абзац + настойчивое желание использовать императивные команды + навязчивое нежелание предоставить ассисенту хоть крупицу дополнительной информации + категоричексая неприемлемость выражения задачи естественным языком + требование уточняющих вопросов от ассистента на произвольную тему, что подразумевает существенно более продвинутые технологии, чем имеется сегодня, + аппелляция к современным технологиям, как только дело доходит до конкретики.
При этом разные части этого супового набора совместимы как красная икра с креозотом.
Весь второй абзац
Второй абзац, для контекста, выглядит так:
Поэтому отработка события, установленного пользователем на 2:30, может (если мы хотим помочь человеку, а не как-формально выполнить команду) быть, в зависимости от задачи, выполнена в 1:30 (если это напоминание о самолёте), в 3:30 (если он в 0:30 поставил таймер, чтобы мясо готовилось 120 минут) или не выполнена вообще (редкий случай - нам, скажем, нужна ночная фотография часов на Спасской башне со стрелками на 2:30).
Слова "эвристики" или синонима не вижу. Единственное, что у меня сопоставляется с этой частью, - слова "в зависимости от задачи", которые не исключают варианта "уточнить".
настойчивое желание использовать императивные команды
При условии того, что до сих пор неизвестно, как гарантировать, что пользователь не станет их использовать.
навязчивое нежелание предоставить ассисенту хоть крупицу дополнительной информации
Какой именно информации? Есть ли общий - и заранее известный, до момента формулировки команды - принцип, как определить, какая "дополнительная информация" здесь нужна?
категоричексая неприемлемость выражения задачи естественным языком
"Поставь будильник на 2:30" - это задача, которую пользователь ставит ассистенту, выраженная естественным языком (другому человеку мы можем сказать дословно то же самое, и это вполне может не выглядеть странно). То, что она не совпадает с целью самого пользователя, этому не противоречит.
требование уточняющих вопросов от ассистента на произвольную тему
На произвольную или конкретно по содержанию поставленной задачи?
аппелляция к современным технологиям, как только дело доходит до конкретики
Что уже выходит за границы "перла", на который идёт ссылка.
Слова "эвристики" или синонима не вижу
Как и алгоритма, классифицирующего задачу. Более того, для классификации задачи явно не хватает данных — остаются эвристики.
При условии того, что до сих пор неизвестно, как гарантировать, что пользователь не станет их использовать.
Каджиту не сложно, каджит и в тринадцатый раз сказать, что задачи пользователя это не решает, а всего лишь патчит один не самый частый случай… толку-то?
Какой именно информации? Есть ли общий — и заранее известный, до момента формулировки команды — принцип, как определить, какая "дополнительная информация" здесь нужна?
Да. Умение формулировать корректные задачи, содержащие необходимые и достачные данные как в секции "Дано" так и в секции "Найти".
"Поставь будильник на 2:30" — это задача, которую пользователь ставит ассистенту, выраженная естественным языком (другому человеку мы можем сказать дословно то же самое, и это вполне может не выглядеть странно). То, что она не совпадает с целью самого пользователя, этому не противоречит.
И, точно так же, как мы можем сказать другому человеку Уася, а давай приедем в аэропорт за два часа до вылета можно попросить ассистента так же составить маршрут.
И это будет более прямым и правильным решением задачи пользователя.
На произвольную или конкретно по содержанию поставленной задачи?
Вы не сможете сформировать задачу с меняющимся условием, поэтому второе уточнение не имеет смысла.
Конкретизация условий в корректно сформулированной задаче (экземпляр) не мешает абстрактной задаче (класс) оставаться произвольной.
Что уже выходит за границы "перла"
Потому что в любом диалоге есть контекст… в данном случае он размазан по десяткам сообщений уже.
Именно так. Человек должен сказать машине - сделай мне хорошо. И машина должна обеспечить ему максимально возможное количество эндорфинов в крови в среднем за жизнь при максимизации продолжительности жизни. Вот это ему надо. А всё прочее - аэропорт, самолёт в шесть утра, часовые пояса и соседний город - человеку не надо.
Осталась самая малость - создать такую машину.
Наконец-то, пришло понимание.
А для сделать базовые кирпичики уже есть, осталось добавить один диалог.
Если бы эти "базовые кирпичики" были, то никаких затруднений не было бы и с обработкой уведомления на 2:30.
Но увы, вы так и не смогли сказать, что машина должна сделать при требовании поставить уведомление на 2:30. Но замахнулись на способность универсально рассчитать время пути в аэропорт, что является задачей на порядки сложнее.
Проблема есть только у вас, и вы все еще настоячиво хотите приписать каджиту.
Но увы, вы так и не смогли сказать, что машина должна сделать при требовании поставить уведомление на 2:30
Это ваше решение поставленной вами же задачи.
Этот сказал лишь что поставленная задача не должна решаться таким путем.
Ну и, есть уж на то пошло, то вы так и не смогли ответить на аналогичный вопрос: на какое время в случае перевода стрелок назад и дубликации времени, нужно поставить уведомление, на 2:30 или же на 2:30.
Но замахнулись на способность универсально рассчитать время пути в аэропорт, что является задачей на порядки сложнее.
Вы только что сказали, простите, что 2ГИС, Google maps, Yandex Навигатор и сотни других — никогда не существовали?
Этот сказал лишь что поставленная задача не должна решаться таким путем.
Поставленная пользователем задача - уведомление на 2:30.
Ну и, есть уж на то пошло, то вы так и не смогли ответить на аналогичный вопрос: на какое время в случае перевода стрелок назад и дубликации времени, нужно поставить уведомление, на 2:30 или же на 2:30.
Конечно, не смог. Вы ж его не задали.
Но ответ весьма простой - уточнить у пользователя: человек, в этих сутках два 2:30, тебе первое или второе?
Собственно, ровно то же решение я и предлагал для отсутствующего времени.
Вы только что сказали, простите, что 2ГИС, Google maps, Yandex Навигатор и сотни других — никогда не существовали?
Я сказал, что они не способны универсально обработать задачу расчёта времени пути. Время пешего перехода конкретного человека (помним, что у нас пенсионер) они не учтут. Время на прогрев машины зимой не учтут (а бывает, что выезд на 10 минут позже - это приезд на 20 минут позже из-за роста пробок). Условие "Едем по разрешенному, но не быстрее 80 км/ч" тоже учитывать не умеют. Собственно, даже переключателя "разрешенная/нештрафуемая скорость " там нет.
Поставленная пользователем задача — уведомление на 2:30
А этот-то думал, требуется решить задачу пользователя.
Впрочем, вы уже не в первый раз говорите, что задачу пользователя решать вообще не надо.
Вы ж его не задали
Хорошо, что компьютеры не забывают, не путаются в показаниях и не подвержены когнитивным искажениям, правда?
Но ответ весьма простой — уточнить у пользователя: человек, в этих сутках два 2:30, тебе первое или второе?
Замечательно. Нет, правда.
А теперь представьте, что напоминалка попадает на валидный интервал, а смена часов происходит в пути — будет ли решена задача пользователя?
При заданном интервале между напоминаем и прибытием в 3:30:00 вероятность такого события будет в 3,5 раза больше.
То есть, этот баг должен быть приоритетнее вашего фикса, потому как поставленная вами задача — успеть на самолет.
Но он менее очевиден, да.
не способны универсально обработать задачу расчёта времени пути
Вполне сособны, и уже годами это делают, включая составные пути.
А органический человек, как раз, может, располагая личным опытом, как дополнительное условие — накинуть еще некоторое время. Точно так же, как он бы сделал и без помощника, и даже без навигатора.
(а бывает, что выезд на 10 минут позже — это приезд на 20 минут позже из-за роста пробок)
А вот тут уже машина будет обладать лучшей статистикой уже сейчас.
Условие "Едем по разрешенному, но не быстрее 80 км/ч" тоже учитывать не умеют.
Согласен.
Но не умеют не потому что это неразрешимая задача вида аналог вк за 1000Р, а потому что нет задачи вводить такое ограничение — и это относительно легко исправить.
А этот-то думал, требуется решить задачу пользователя.
Да. Требуется решить задачу пользователя. Либо, если задачу решить нельзя - сообщить пользователю об этом.
То есть, этот баг должен быть приоритетнее вашего фикса, потому как поставленная вами задача — успеть на самолет.
Нет, поставленная пользователем задача - уведомление на 2:30. Её и надо решать. Для чего он её такую поставил - это его личное дело. Может, на самолёт, может, мясо приготовить, а может, часы фотографировать - мы не знаем.
Хорошо, что компьютеры не забывают, не путаются в показаниях и не подвержены когнитивным искажениям, правда?
Правда. Вопроса там нет (вопросы заканчиваются знаком вопроса, коих там нет).
Вполне сособны, и уже годами это делают, включая составные пути.
Отлично. Расскажите, пожалуйста, какой общедоступный на сегодня навигатор позволит решить задачу "Дойти до гаража пешком со скоростью 4 км/ч, прогреть машину в течение 10 минут, поехать в аэропорт по ПДД и не быстрее 80 км/ч"? Вот прям так, чтобы можно было открыть и проверить.
Да. Требуется решить задачу пользователя. Либо, если задачу решить нельзя — сообщить пользователю об этом.
И сейчас этот снова спросит, какова же задача пользователя, а вы снова не сможеде в декомпозиуцию и причинно-следственные связи, но будут путаться в показаниях.
Уже проходили, недавно.
… поставленная пользователем задача …
В том, что вам удобнее подменять задачу пользователя (которая описана вами же декларативно) на подзадачу, поставленную пользователем в ходе решения задачи пользователя (выраженную в виде части этого решения, причем императивно) — этот тоже заметил.
И акцентировал на этом внимание еще в первом же комментарии.
Вопроса там нет
К воротам добавляется риторический вопрос. Stop the baa.
Расскажите, пожалуйста
Попробуйте прочитать и осмыслить прочитанное.
Наличие прямо сейчас физической реализиции с вашими хотелками в открытом доступе вы придумали сами, а требуете ее предъявить от каджита.
А вот композитные пути можете посмотреть на практически любом навигаторе, если выберете ОТ в качестве средства перемещения. В 2ГИС можно выборочно отключать отдельные виды транспорта, например.
Дело за малым, отметить точки "гараж" и "платная парковка при аэропорту", и научить его использовать эти точки для построения а/м маршрута вместо ОТ.
В том, что вам удобнее подменять задачу пользователя (которая описана вами же декларативно) на подзадачу, поставленную пользователем в ходе решения задачи пользователя
Именно так. Задача, которую поставил пользователь - описана: уведомление на определенное время. И голосовой помощник должен не "решать задачу пользователя", а в первую очередь "решать задачу, поставленную пользователем перед голосовым помощником". А зачем и почему он поставил такую задачу - факультативно уточнить. Один человек попросит вызвать такси в аэропорт с прибытием в 6 утра. Другой - напомнить об отъезде так, чтобы приехать в 6 утра. Третий посчитает в уме и попросит поставить напоминание на определенное время. И голосовой помощник - если он помощник, а не бессмысленный кусок железа - должен в каждом случае предельно точно сделать то, чего требует от него пользователь. Или, если это невозможно - (данного времени нет в сутках или такси нельзя вызвать заранее) - сообщить об этом понятно для пользователя.
А как только программист решает, что он лучше пользователя знает, что нужно пользователю - он создаёт продукт, которым простой пользователь пользоваться без обучения не может. Ещё раз: либо ваш помощник нормально обрабатывает требование уведомления на любое время, либо летит в корзину, потому что рядовой пользователь не будет строить сложные формулировки там, где в 99% случаев можно обойтись простыми. А в 99% случаев задачи "будильник на 2:30" и "будильник за 3:30 до 6:00" абсолютно идентичны.
Дело за малым, отметить точки "гараж" и "платная парковка при аэропорту", и научить его использовать эти точки для построения а/м маршрута вместо ОТ.
Ну вот когда научат, тогда и поговорим. Сейчас ни один доступный навигатор описанную задачу решить не может - о чём я собственно и написал.
Именно так. Задача, которую поставил пользователь — описана:
Правильно. А что сказал каджит?
В данном случае задача выйти из дома за 3.5 часа до рейса, а не выйти из дома в 2:30.
Как думаете, почему? Вопрос риторический.
Когда сможете отличить задачу пользователя от части решения задачи пользователя, оформленной в виде подзадачи для передачи другому исполнителю, тогда появится смысл продолжать разговор.
А пока ты ему про Фому, а он тебе про Ерему — М'Айк устал, приставай к кому-нибудь другому.
А пока ты ему про Фому, а он тебе про Ерему
Собственно, да.
Я вам раз за разом пишу, что пользователь может по незнанию, по забывчивости, по неумению формулировать - поставить нерешаемую задачу, и это требование придётся обработать (например - переспросить), если вы хотите создать продукт для массового пользователя.
Вы мне раз за разом пишите, что пользователь должен формулировать задачу так, чтобы она гарантированно была решаемой. Ну, в общем, да, вам так было бы удобнее. Но он всё же может поставить нерешаемую. И крайне желательно её суметь обработать.
-- Что будет, если пользователь поставит будильник на 26 часов 17 минут?
-- А пусть не ставит.
-- А если постваит, то что будет?
-- А пусть не ставит.
-- А если всё-таки поставит?
-- А пусть не ставит.
А этот-то думал, требуется решить задачу пользователя.
А какая у пользователя задача? Почему вы решили, что если он едет в аэропорт, он собирается из него улетать? Может это встречающий? Или ему по-пути просто
Ну так пользователь же скажет. Он обязан догадаться, что помощник будет решать его задачу, а не помогать с какой-то конкретной частью (например - с будильником).
Проблема в том, чтобы пользователь осознал, что его задача — это только часть общей задачи, и вместо озвучивания части озвучил всю задачу. Тут правда возникает вопрос, а когда он должен остановиться, охватывая все более и более обширные задачи? Почему, скажем, он должен остановиться на фразе "нужно на самолет", а не "хочу отдохнуть", или "нужно в командировку"? В конце-концов, самолет сам по себе ему не нужен, если следовать логике khajiit, а значит и озвучивать эту задачу он не должен.
Следуя логике каджита (опустим пока тот момент, что логика это раздел математики, и она на всех одна), декларативно-выраженная задача успеть на самолет не должна решаться императивной командой установить напоминание, потому что это влечет за собой массу скрытых проблем.
Да, давайте возведем степень идиотии в абсолют, сказав, что пользователь понятия не имеет, чего хочет)))
Правда, в этом случае ассистент ему становится бесполезен, что вообще лишает задачу какого-либо смысла.
Но ведь это именно вы отказываете пользователю в разумности, заявляя, что его задача — и не задача вовсе, а нужна ему совсем другая задача.
Задача сформулирована вот тут
Вот она:
у человека самолёт в 6 утра. И, чтобы успеть
А дальше начинается веселое:
ему надо выйти из дома в 2:30, т.е. за 3.5 часа до рейса. А про перевод времени он забыл
В выделенном жирным отлично видно, что пациент прекрасно понимает и задачу и важность относительной формулировки времени.
Но использует абсолютную, специально чтобы породить проблему.
Это хорошая иллюстрация неприменимости такого подхода, в силу его проблематичности.
А вот дальше начинается какой-то сюр…
Этот не уверен, но похоже, что konst90 вообще считает таймстемпом то, за что по пальцам бьют ребром стального метра: локальное время с отброшенной таймзоной.
Ок, действительно, реальная проблема была поставлена. Действительно, если бы пользователь именно ее и озвучил ассистенту, задача ассистента упростилась бы.
Однако даже в искаженной формулировке еще есть шанс, что исходная задача будет выполнена, если ассистент, используя косвенные признаки (отсутствия на шкалах времени[1] точки, которая представляется как 2:30), попытается получить дополнительную информацию (т.е. переспросить).
Но использует абсолютную, специально чтобы породить проблему.
Конечно, ведь вся суть его комментария и показать проблему, поэтому он ее порождает.
[1] В этой задаче на самом деле 2 шкалы времени: до перевода часов и после. В принципе, точки на этих шкалах имеют разные типы, только в реальности пользуются или одной, или другой, поэтому их текстовое/вербальное представление одинаковое. Это та же проблема, что с Юлианским/Григорианским календарем — прыжки времени есть только в воображении, когда пытаются прикинуться, что у нас даты имеют один тип "дата", вместо того, чтобы признать, что их два — "дата_в_юлианском_календаре" и "дата_в_григорианском_календаре". Записываются одинаково, но в исторических документах сначала используется тип "дата_в_юлианском_календаре", а после какой-то точки — "дата_в_григорианском_календаре". Но если не знать точки смены календаря и иногда личности пишущего и обстоятельств написания документа, из их никак не различить.
Ок, действительно, реальная проблема была поставлена. Действительно, если бы пользователь именно ее и озвучил ассистенту, задача ассистента упростилась бы.
Именно. И каджит виноват лишь в том, что заметил это и сказал об этом.
А потом начались попытки приписать этому заведомо неправильное решение, всячески сместить, размыть и подменить тему обсуждения, увести разговор в частности, и т.д. и т.п.
Вот и имеем что имеем.
Круче. Он обязан догадаться, что помощник справится с задачей "Алиса, поставь уведомление на выход из дома так, чтобы я дошёл до гаража, прогрел машину, заехал за дочкой и привёз её в аэропорт к 6:00" (вариативно - либо найдя в памяти, где находится гараж и дочка, либо потребовав уточнить адреса, либо пользователь должен усложнить команду ещё и на два адреса). При этом зная, что помощник не осилит правильно обработать "Алиса, поставь уведомление на 2:30" (потому что если осилит, то я вообще не понимаю, чего хочет каджит).
Если он встречающий, то ему надо успеть не к отправке а к прибытию (+некоторый промежуток на прохождение формальностей, опять же) — задача, по сути, не меняется: успеть к указанному времени.
Если по пути — то это не задача, а промежуточная точка, задача другая.
У вас человек из людей, которые прекрасно разбираются в слесарном деле, но голосовой помощник для них — чудо чудесное высчитывает время.
Это значит, что вы уже заставили его считать. Вместо того, чтобы просто озвучить свою задачу.
Вы забываете, что этот человек не был воспитан голосовыми помошниками, а купил его недавно. И до этого всю свою жизнь сам считал время, скорее всего даже в уме.
И это совершенно не противоречит утверждению, что надо оставить работу машины — машине.
Более того, скорее даже является аргументом в его пользу… Потому что, по условиям, человек уже ошибся.
У вас просто нет варианта оставить работу машины — машине. Потому что пользователь её уже выполнил, и не знает что нужно делать как-то иначе.
надо оставить работу машины — машине.
Проблема за малым - создать машину, которая сумеет делать работу машины.
"Алиса, мне нужно быть в аэропорту в 6 утра, а перед этим дойти до гаража по адресу такому-то, потом заехать по адресу такому-то и оттуда в аэропорт". Сумеет ваша машина это сделать? С учётом пробок на маршруте, скорости пешей походки данного человека, времени на прогрев машины (разное летом и зимой) и так далее.
Непонятно только, почему для такой умной машины непреодолимой проблемой станет сказать, что 2:30 в нынешних сутках отсутствует.
Ух ты, организация маршрута до аэропорта у нас превратилась в распорядок дня )
А если эта проблема тоже окажется решаемой, вы Луну с неба потребуете, лишь бы не признавать, что фигню сморозили?
Непонятно только, почему для такой умной машины непреодолимой проблемой станет сказать, что 2:30 в нынешних сутках отсутствует.
А вот эту проблему вы выдумали сами, и настойчиво пытаетесь вменить ее каждиту в вину.
Возможно, стоит напомнить, что мы находится в комментах под статьей о ошибках относительно постоянства времени.
И ваш вариант по прежнему является наглядной иллюстрацией заблуждений №10 и №4.
Из них есть одно интересное следствие, до понимания которого вы пока не дошли, касательно интервала ошибки, и того, что ваш вариант решает только один конкретный случай при конкретных условиях.
А вот эту проблему вы выдумали сами
Я задал (раз пять уже) простой вопрос: как машина должна обработать уведомление на несуществующее время. Вы вместо простого ответа раз за разом растекаетесь мыслью.
А вопрос, собственно, был задан для демонстрации весьма простой мысли: арифметика с таймштампами в некоторых случаях недостаточна и требует дополнительной (хотя и весьма простой) обработки.
Я задал (раз пять уже) простой вопрос: как машина должна обработать уведомление на несуществующее время. Вы вместо простого ответа раз за разом растекаетесь мыслью.
Вам уже с дюжину раз сказано: сюда не хады, туда хады — там этат вапроз вабще не вазныкаит (и попутно решает десяток других, до которых вы еще не добрались.
Иначе говоря, вам про архитетуру решения, а вы все про обработку конкретного исключения, которая после смены арзхитектуры становится ненужной.
Ворота, это konst90; konst90 — это ворота.
арифметика с таймштампами в некоторых случаях недостаточна и требует дополнительной (хотя и весьма простой) обработки
Этот надеется, что вы не из тех, кто сохраняет свое локальное время без TZ на удаленный сервер, а потом использует сохраненное как тайпштамп…
обработку конкретного исключения, которая после смены арзхитектуры становится ненужной.
Никакая смена архитектуры не избавит вас от человека, который может потребовать поставить уведомление на несуществующее время, и соответственно необходимости это невыполнимое требование обработать.
Хосьпидя…
Знаете как работают системы сбора логов?
- берем таймстемп
- приводим его к UTC
- отправляем в хранилище
- на клиенте выполняем конвертацию в таймзону клиента
Это позволяет единообразно решать задачи вида посмотреть, что происходило произвольное время назад (делать вычисления вида прибыть в аэропорт за два часа до вылета).
При этом никаких невалидных времен просто не возникает.
В какой-то момент их захочется показать пользователю. И пользователь хочет что-то более удобное, чем одно длинное число. Более того, пользователь хочет что-то, что он сможет соотнести со своими часами на стене. Также бизнес-логика приложения может включать в себя понятия типа "каждый день", "каждый месяц" (например, списание оплаты за услугу) и т. п. А этих понятий принципиально нет в timestamp. И что делать?
А в чем проблема хранить и передавать время в UTC? Я вот действительно не понимаю. Ну будем вставать в условном Урюжопинске не в 8:00, а в 13:00? Так и рабочие часы организаций можно указывать не с 9:00-18:00, а 14:00-23:00. Привыкнуть можно. Зато везде и одинаково. Что б не будить никого в Хабаровске просто потому, что на сайте не написано где у них офис (почти реальный случай у меня, там был не Хабаровск, а поближе).
Китай так и живет. В принципе можно. Но нужен глобальный консенсус для этого. А это невозможно.
Неудобно, когда дата меняется посреди рабочего дня.
Если глобализация все же продолжится, то со временем к чему-то такому и придем. Я работаю с распределенными командами. Для коротких интервалов удобно использовать относительное время (собираемся через 30 минут, а не во столько-то часов, что каждый будет трактовать по-своему). Для чего-то регулярного или глобального наружу используется UTC.
Забыли про заблуждение, что время придумали часовые компании, чтобы продавать больше часов
Чем древнее, тем говнее! (с) Клим Александрович Жуков
Недели не везде семидневные, в Мьянме неделя восьмидневная, из уважения к священности числа 8 в буддизме. Но не в том смысле, что дни отсчитываются по восемь, а просто среда до полудня и после полудня – два разных дня. Зато при этом начинающаяся с воскресенья неделя делится на две равные части.
Зато представьте - как нам повезло хотя бы в том, что секунда у всех одинаковая. Нет никакой имперской секунды или дошедшего до наших дней и стандартизованного "удара сердца самурая", которым бы пользовались где-нибудь в Японии.
Unix timestamp везде одинаковый ))
Уф. Как всё сложно-то! Спасибо за стать, очень интересно.
Заблуждение 3. В месяце 30 дней
В немецкой финансовой сфере это "заблуждение" вполне в ходу и не считается ошибкой (по крайней мере в определённых сферах). Называют "методом 30/360": https://de.wikipedia.org/wiki/Zinsberechnungsmethode#30/360_–_deutsche_(kaufmännische)_Zinsmethode
Как и говорит название Kaufmännische - торговый - это применимо и очень удобно в банковской сфере и торговле. Точность до дня там не играет никакой роли вообще, потому что важно как договорились, а не как оно "теоретически могло бы быть". А вот расчёты сильно упрощаются.
Собственно потому этот метод и возник. Например, кредит на 20 лет как 240 равных 30-дневных месяцев можно один раз расчитать аналитически, и он остается верным для выбранной ставки. А по act/act (точный учёт дней) нужно пересчитывать на каждый день отдельно. Потому в докомпьютерное время этот метод и возник, а сейчас по инерции используется.
Еще одно заблуждение в копилку.
Эра - это долго, как минимум больше ста лет. И кратна году. Солнечному или лунному. Ну пожалуйста.
Но не в Японии. Японская эра привязана к периоду царствования очередного императора.
Эра Хэйсэй (平成) — длилась с 8 января 1989 года по 30 апреля 2019 года.
Текущая эра Рэйва (令和) началась на следующий день. Когда закончится - никто не знает, царствующему императору Нарухито 62 года, искренне желаю ему многая лета.
В связи с наступлением новой эры был введен новый иероглиф “㋿” (U+32FF) и новый стандарт Unicode 12.1. Потом каскадно обновлялись программы и фреймворки, например JDK 8 update 211.
часть островных государств находится в Южном полушарии, за линией перемены даты
Может всё-таки в Западном?
Заблуждение 3. В месяце 30 дней
У некоторых финансистов так и есть. Конвенция 30/360 по-прежнему встречается на рынках облигаций и деривативов на процентные ставки. Это довольно удобно для устного счёта: если годовая ставка 6%, то за любой календарный месяц кредит зарабатывает 6%/12 = 0.5%, а за любые полгода 3%, и не надо высчитывать количество дней в месяцах и вспоминать, високосный ли февраль. Опять-же, топ-менеджмент банка не прибегает к программистам в панике в начале марта из-за того, что в феврале процентный доход банка уменьшился по сравнению с январём на 10% (28 / 31 - 1 = -9.6%).
https://en.wikipedia.org/wiki/Day_count_convention#30/360_methods
Я думаю, топ-менеджмент банка получше программистов в курсе про процентный доход :)
Я выше ответил - если Вы представите как только расчитать аннуитет на 20 лет до изобретения программистов, Вы легко поймёте в чем реальный смысл 30/360.
А вот сейчас уже часто встречается учёт реальных дней, менеджеры понимают.
Большинство проблем от того, что в человеческой культуре слова «время» и «календарь» используются не вполне точно. Время, как непрерывная и монотонная величина, измеряется только секундой, ну или любой другой величиной. А всё остальное - это календари в самом широком смысле. С календарями человек делает что угодно - переводит время скачками, на лето, еще куда-то. Имеет право, да, но изначальное понимание о фундаментальном различии времени и календарей должно заставить думать о переводе одного в другое.
А високосные секунды и, как следствие, неравномерность time_t - хороший пример того, как это заблуждение о времени и календарях прорастает даже в самых умных головах.
Имхо, время в GPS, лишенное високосных секунд - пример более удачного подхода. А вот Глонасс с високосными - неудачный. Теперь одним можно ничего не делать, а другим придется переписывать.
Время, как непрерывная и монотонная величина – тоже концепция, привязанная к определённой культуре, либо к определённой физической модели. Традиционное для человеческой истории понятие времени как раз циклическое, связанное с чередованием дня и ночи, сельскохозяйственных сезонов и так далее. Это ещё кто-то для начала должен был додуматься до концепции интервалов времени больше года и их измерения.
Что касается физической модели, с ней тоже не всё гладко. Например, задают такой вопрос: что было в первую секунду после Большого Взрыва? В ответ на это логично спросить, а что в данном случае вкладывается в понятие “секунда”? Если 9 миллиардов колебаний возбуждённого атома цезия, как пишут в физическом справочнике, то никакого цезия тогда не было. Вот и что делать с этим?
Вот и что делать с этим?
пересчитывать на то что было в то время - время осцилляций каких-нить кварков или нейтрино
Ведь время - относительно - это то вы понимаете? (С)
В любой процессорной технике время - непрерывно и монотонно. Да и у людей и вообще чего угодно. Это свойство вселенной. Пока мы договорились измерять атомами цезия. И по своей сути это счетчик, непрерывный и монотонный.
а вот мыслим мы традиционно в контексте календарей, хотя называем это тоже «временем».
Задачи поиска точек во времени звучат обычно так - «через неделю», или «1 числа каждого месяца» или «ежедневно в 00:05». Между тем всё это отсылка к календарям. А таймер на железе должен сработать в непрерывной и монотонной системе. Перевод из системы в систему требуется неизбежно. Но в силу вот этой языковой вольности очень часто ускользает от разработчика.
В любой процессорной технике время - непрерывно и монотонно.
вот как раз нет. И особенно нет в х86
В любой процессорной технике время - непрерывно и монотонно
Пока не пришел пользователь и не поменял время из каких-то свих соображений.
В распределенных системах все еще веселее. На разных узлах время может быть произвольным. Прям вообще произвольным. А в самых запущенных случаях оно еще и идет с разной скоростью.
Ну вспоминается определение из одной НФ-книги :)
Радиотранслятор снова ожил. Достопочтенная Глория Сесили Лоу продолжала:
— На тот случай, если ваши меры времени расходятся с нашими, сообщаю, что наш день содержит двадцать часов по сто минут в каждом. Минута состоит из ста секунд, причем за одну такую секунду свет проходит ровно сто тысяч миль. Постарайтесь точно выдержать отведенный Вам срок. Через неделю я обращусь к Вам снова.
Правда вот автор забыл указать что значит "миля" (и какая именно) (по сюжету там это часть обращения к группе давно потерянных колоний)
Имхо, время в GPS, лишенное високосных секунд - пример более удачного подхода. А вот Глонасс с високосными - неудачный. Теперь одним можно ничего не делать, а другим придется переписывать.
Не так. В ГЛОНАСС придётся переписывать борт, а в GPS – все приёмники.
Я несколько не понимаю, где там (что там, что там) вообще високосную секунду можно воткнуть. 'Прошло xyz.abcd мегасекунд от сотворения мира (c учетом поправок теории относительности - говорят, там это уже нужно учитывать)' - ну и пусть тикает монотонно. А то что на циферблате показывается - как-нибудь потом пересчитаем, оно для расчета координат вроде бы не должно быть нужно.
Ещё точнее - проблема в том, что "в быту" для измерения времени исторически прижились несколько взаимно некратных величин (сутки, год), от которых по странным схемам пошло формирование кратных:
Час, минута, секунда - 1/N доля от суток. А почему не 1/М?
Месяц - примерно 1/12 от года, т. е. примерно 30 суток. А почему не 1/13?
Неделя - 7 суток. А почему не 8 и не 6?
Век - 100 лет, ну тут хотя бы понятно почему.
В итоге у нас неделя не совпадает с годом и месяцем, сутки не совпадают с годом и нужно городить костыли, цифры везде какие-то непонятные, в секунде не 60 миллисекунд...
Фактически, нужно найти те точки, которые являются объективной реальностью, подружить их, а остальное отдать на откуп математическому удобству.
Час, минута, секунда — 1/N доля от суток. А почему не 1/М?По арифметичко-астрономическим причинам. У 60 делители — 2,3,4,5,6. Это очень удобно, если вы не можете в дроби, но делить хотите. И к тому же в году примерно 60*6 = 360 дней. Очень очевидный и удобный выбор!
Месяц — примерно 1/12 от года, т. е. примерно 30 суток. А почему не 1/13тупо Луна. Её цикл в среднем ближе к 1/12. Ну и женский цикл… Ну и опять-таки 12 — делить удобно (симестр/триместр/квартал)
Неделя — 7 суток. А почему не 8 и не 6?Четверть лунного месяца. Почему четверть? — потому что по четвертям фазы луны отслеживать легко. Даже считать дни не надо!
Так что всё просто и очевидно! Это как с дюймами и футами, со всякими денежными единицами и т.п.: вроде как бред, но конкретно в тех условиях, когда всё это формировалось это было очень удобно и чуть ли не единственный массово доступный способ измерения.
Меня больше всего удивляет перевод времени из 24 часового формата в 12 часовой: между 11:58 am 11:59 am всего 1 минута, а между 11:59 am и 12:00 am полдня, а точнее 11 часов и 59 минут.
Оказывается, в репозиториях Debian 11.5 «bullseye» нет cal
Есть ccal.
Команду ccal sep 1752 утилита отрабатывает без интересующих нас искажений.
Кто-то где-то в интернете "задротливо" учитывает весь этот ужас и вовремя подправляет в своей библиотеке на ГитХабе?
Также значит, что можно лишь усмехнуться от очередного гения/таланта на ТВ, который может назвать день недели по любой дате, которую ему назовут, да?
Конечно. Java периодически обновлять tzdata - https://github.com/openjdk/jdk/commit/54c986e7d5d0b48a22b4da81c13153ce431c9f2f
Был в этом музее, безумные впечатления оставил
Не все страны или их части переводят часы на лето. К примеру, штат Аризона от этой практики отказался в 1968, хотя остальные материковые США сохраняют традицию.
За исключением резервации Навахо, где часы переводят (как в остальных штатах); но в ней есть резервация-анклав Хопи, где перевод часов отменили (как в остальной Аризоне).
"Разница в 3 минуты 56 секунд случается потому, что Земля совершает полный оборот вокруг Солнца за то время, что ей нужно совершить около 366,25 оборотов вокруг своей оси".
Прошу прощения, может дальше где есть уточнение, но 3 года по 365 суток, 4-й високосный, 366. Сутки так и копятся?
Может всё-таки 365,25?
Солнечные (синодические) сутки — это время оборота плюс ещё небольшой доворот к Солнцу. Вот они равны 24 часам.
Звёздных суток в году на одни больше, чем солнечных.
1-2 — звёздные сутки, 1-3 — солнечные сутки.
Вы когда вокруг Кибердемона в Doom (1993) стрейфите круги, вы оборот вокруг своей оси совершаете? Если бы не совершали, то вам бы не пришлось менять угол прицеливания, прикасаясь только к клавишам движения. Но для стрейфа нужно поворачиваться вокруг своей оси.
Аналогичным образом и Луна стрейфит вокруг Земли. (Да, я объясняю астрономию в терминах шутеров от первого лица.) Луна синхронизирована в своём вращении, то есть совершает оборот вокруг своей оси за примерно те же время, что ей нужно совершить оборот вокруг Земли. Если бы она этого не делала, не существовало бы понятия «обратная сторона Луны» и научной значимости чёрно-белого снимка советского зонда «Луна-3».
Если посадить наблюдателя в кратер Тихо, он целый лунный месяц будет видеть Землю. Если его попросить игнорировать все остальные небесные тела, то с его точки зрения ни одного оборота Луна не совершила, лишь колебаясь либрациями.
Примерно так же между двумя точками, скажем, осеннего равноденствия Земля с точки зрения стороннего наблюдателя (удалённых неподвижных звёзд) совершает около 366,242199 оборотов вокруг своей оси. Хотя с Земли восходов и закатов будет в среднем около 365,24.
23 часа 56 минут 4 секунды — это длина сидерических суток.
В Молдове, Крыму и Грузии Рабочая неделя с воскресенья по четверг, также как в Антарктиде и Конго? Почему-то, очень в этом сомневаюсь. Особенно сомневаюсь насчёт Конго.
Очень удобно(нет) использовать серый цвет в качестве информационного. Особенно, если им же указывать отсутствие информации.
Так помимо самих дат, ещё учитывать то, как их отображать пользователю (форматы в «Язык и региональные стандарты» | «Region and Language»)…
Вот как заставить 8-ку и 10-тку показывать месяц римскими цифрами (MMM)? На 7-ке каким-то чудом это найти удалось при Монгольском формате — но на 10-тке ровно точно такая же настройка не прокатывает :(!
Всякие "генераторы" имён файлов (снимки/видеозахват экрана/камер/звука и т.д.) "подразумеваемый месяц" назло настройке системы записывают исключительно арабскими цифрами! Ну так чтоб не портить "сортировку по именам", вместо комбинаций из латинских букв — U+2160‥U+2179. Разве что для записи самого года римскими цифрами ещё вопросы остаются, хотя, чего уж там: даже для %y%m%d(%t) с припиской "AM"/"PM" после минут…
Так вот к чему это я: пора делать систему так, что сами имена файлов (не их атрибуты) могли содержать "код даты-времени", чтоб это имя отображало по-разному в зависимости от локализации/региональных настроек!
Для локализации статических имён файлов хватает desktop.ini :)
Не надо. Не хватало еще ловить баги когда файл имеет разное имя в зависимости от локали.
Для человекопонятной сортировки есть старый и работающий ISO date time format. Все им пользуются и довольны.
Любопытно, что наше обычное европейское время - 15:00, 19:15, 23:55 - в Америке называется "военное время".
Потому что обычный американец делит циферблат на "до полудня" и "после полудня". А точное время используют только военные. Причем, они используют время без двоеточия и называют часы сотнями, а слово "минуты" не произносят.
Пятнадцать сотен. Девятнадцать сотен пятнадцать. Двадцать три сотни пятьдесят пять.
Прикольно, что мы все понимаем секретный язык американских военных.
© Татьяныч
Заблуждения программистов о времени