Comments 100
А где контрпримеры по каждому пункту?
Очень не хватает, ибо многие моменты требуют наглядного пояснения.
Год за годом в процессе роста сеточки с добавлением железочек, программочек и др. так наплясался со временем, что безоговорочно верю каждому пункту.
1. Разность между двумя часовыми поясами будет оставаться постоянной.
Подвижки часовых поясов в России за последние годы
2. Хорошо, отставляя в сторону исторические курьёзы, разность между двумя часовыми поясами не изменится в будущем.
И они еще могут быть
3. Изменение разности между часовыми поясами будет происходить с выдачей множества предварительных оповещений.
Мне кажется, в примерах не нуждается. И так понятно, что — всяко бывает.
4. Переход на летнее время происходит каждый год в одно и то же время.
СССР переводился, вроде, с воскресенья на понедельник. Сейчас — на выходных.
5. Переход на летнее время происходит в каждом часовом поясе в одно и то же время.
Аналогично.
6. При переходе на летнее время всегда происходит сдвиг на один час.
Недавний перевод часов в России — часть областей уехала на иное количество часов.
7. Количество дней в месяце составляет 28, 29, 30 или 31.
1582 год. У католиков в октябре после 4-го числа сразу настало 15-е.
8. День месяца всегда изменяется последовательно с N на N+1 или на 1 без какого-либо разрыва.
См. предыдущий пункт
9. В каждый момент времени используется только одна календарная система.
Мусульмане и ряд восточных стран одновременно могут пользоваться несколькими календарями.
10. Високосный год имеет место в каждый год, который делится на 4.
1900-й и 2100-й года — невисокосные.
11. Невисокосный год никогда не имеет 29 февраля.
С этим сложности. Я не знаю контрпримеров.
12. Легко сосчитать количество часов и минут, прошедших с какого-то определённого момента времени.
Взять, например, переход Швеции на григорианский календарь. Там мозг сломать можно уже на описании — даже не расчете…
13. Один и тот же месяц содержит одно и то же число дней везде!
Переход на григорианский был различен в разных странах.
14. Время в Unix измеряется только в секундах.
Видимо, имеется в виду, что «реальное» время во время добавления високосной секунды составляет две секунды, когда в Unix фиксируется только одна секунда (соответственно, это может быть чревато для промобъектов, вычисления скорости и так далее).
15. Время в Unix представляет собой количество секунд, начиная с 01 января 1970 года.
Високосные секунды отбрасываются.
16. Субботе всегда предшествует пятница.
Переход через линию перемены дат (ЛПД) в полночь позволит попасть в субботу из четверга. Ну или из субботы.
17. Соседние часовые пояса различаются не более чем на один час (другими словами: мы не должны проверять, что происходит с авиационной электроникой при пролёте над линией перемены даты).
ЛПД
18. Два разных часовых пояса различаются на целое число получасовок.
Непал и Индия. Отличие — 15 минут.
19. Ладно, на целое число четвертей часа.
Не знаю контрпримера
20. Ладно, на секунды, но это будет существенная разница, если мы не учитываем переход на летнее время.
Не знаю контрпримера
21. Если вы создаёте два объекта даты прямо рядом друг с другом, то они будут представлять одно и то же время (фантастический генератор Гейзенберга).
Не понял сути.
22. Можно подождать, когда часы покажут точно ЧЧ: ММ: СС с дискретизацией один раз в секунду.
При високосной секунде часы могут не показать 23:59:60
23. Если процесс идёт «n» секунд, а затем завершается, то приблизительно «n» секунд прошло на системных часах к моменту завершения.
Високосная секунда.
Или в момент перевода часов.
24. Неделя начинается в понедельник.
США — в воскресенье.
25. День начинается утром.
Не знаю контрпримеров.
26. Праздники занимают целое число полных суток.
Не знаю контрпримеров.
27. Выходные дни состоят из субботы и воскресенья.
Переносы выходных дней из-за праздников.
28. Можно установить общий порядок формирования временных меток, который будет полезен за пределами вашей системы.
Не понял сути.
29. Смещение местного времени (относительно универсального синхронизированного времени (UTC)) не изменится в течение рабочего дня.
Перенос часовых поясов круглосуточного производства.
30. Thread.sleep(1000) приостанавливает выполнение на 1000 миллисекунд.
Високосная секунда.
31. Thread.sleep(1000) приостанавливает выполнение на время >= 1000 миллисекунд.
Не знаю контрпримера.
32. Каждая минута содержит 60 секунд.
Високосная секунда
33. Метки времени всегда продвигаются монотонно.
Високосная секунда
34. Среднее время по Гринвичу (GMT) и универсальное синхронизированное время (UTC) представляют один и тот же часовой пояс.
Не знаю контрпримера
35. Великобритания использует среднее время по Гринвичу (GMT).
Перешли на UTC по причине неравномерности GMT из-за неравномерности вращения Земли.
36. Время всегда идёт вперёд.
Физически — не знаю контрпримера. Но местное при пересечении ЛПД может идти и вспять…
37. Разность между текущим моментом времени и моментом времени, отстоящим на одну неделю, всегда равна 7 * 86400 секунд.
Високосная секунда
38. Разность двух меток времени является точной мерой времени, прошедшего между ними.
Високосная секунда
39. 24:12:34 — неправильное время.
Не знаю контрпримера.
40. Каждое целое число теоретически может означать год.
Не понял смысла фразы.
Может, имеется в виду, что минус триллион не имеет смысла в нашей Вселенной?
Нулевой год используется астрономами.
41. При выводе на дисплей даты и времени показываемое время имеет ту же самую вторую часть, что и время, хранимое в памяти.
Не понял, что есть вторая часть. Возможно, имеется в виду сегмент секунд или их доли?
42. Или тот же год.
На время отрисовки (ненулевое) может прийтись новый год.
43. Но, по крайней мере, разность между показываемым и хранимым годом не превышает 2.
Не знаю контрпримеров.
44. Если данные находятся в правильном формате ГГГГ-ММ-ДД, то год содержит четыре цифры.
382-12-01 — первое декабря 382-го года, очевидно, либо должно иметь фильтр на ввод, требующий вбивать 0382, либо обрабатывать и такие варианты.
45. Если происходит слияние двух дат путём заимствования месяца из первой, а дня и/или года — из второй, то дата получается правильной.
Сливаем 20 февраля и 31 января. 31 февраля, мне кажется, еще не случалось.
46. Но это будет работать, только если оба года — високосные.
Аналогично.
47. Если взять опубликованный алгоритм, описанный спецификацией W3C, для добавления некоторой продолжительности к датам, то он будет работать во всех случаях.
Не знаю контрпримера.
48. Стандартная библиотека поддерживает отрицательные годы и годы, превышающие 10000.
Не готов прокомментировать.
49. Часовые пояса всегда различаются на целый час.
Непал-Индия.
50. При преобразовании метки времени, имеющей точность в миллисекундах, во время, имеющее точность в секундах, можно спокойно не учитывать составляющие в миллисекундах.
Не готов комментировать.
51. Можно не учитывать составляющую в миллисекундах, если она менее 0,5.
Не готов комментировать.
52. Год, представленный в виде двух цифр, должен быть в диапазоне 1900-2099.
А может и не быть. И как трактовать 42? Это 1942 или 2042?
53. При синтаксическом анализе времени, даты можно читать числа последовательно (символ за символом) без необходимости возвращаться назад.
Не готов комментировать.
54. При распечатке времени, даты можно писать числа последовательно (символ за символом) без необходимости возвращаться назад.
Не готов комментировать.
55. У вас никогда не будет необходимости выполнять синтаксический анализ примерно такого формата ---12Z или P12Y34M56DT78H90M12.345S.
Не готов комментировать.
56. Имеется только 24 часовых пояса.
Больше. Даже если не учитывать получасовые и четвертьчасовые извращения, а также (не)переход на зимнее, часовых поясов есть от -12:00 до +14:00.
57. Часовые пояса всегда различаются на целое число часов относительно универсального синхронизированного времени (UTC).
Индия-Непал
58. Переход на летнее время везде начинается/заканчивается в один и тот же день.
Не знаю контрпримеров.
59. Переход на летнее время всегда представляет собой сдвиг на 1 час вперёд.
Подвижки поясов в России.
60. Считывание часов клиента и сравнение с UTC является хорошим способом определить часовой пояс клиента.
Не учитывает летнее-зимнее время, да к тому же клиент может иметь непереведенные часы (например, пребывать в командировке в другом часовом поясе).
61. Программно-реализованный стек будет / не будет пытаться автоматически настроиться на часовой пояс / переход на летнее время.
Не готов комментировать.
62. Моя программа используется только внутри предприятия / локально, поэтому мне не надо беспокоиться о часовых поясах.
Ну, если подвижки времени вообще ни на что не влияют, то в ряде очень отдельных случаев — возможно.
Но полагаться на это по умолчанию — не стоит.
63. Мой программно-реализованный стек будет обрабатывать это без необходимости какого-либо моего вмешательства.
Не готов комментировать.
64. Я могу легко сохранить список часовых поясов сам.
После чего опять произойдет нормотворческий зуд у какого-нибудь политика…
65. Все измерения времени на данных часах будут происходить в одной и той же системе отсчёта.
В сильно специальных условиях — возможно. Но надо проверять.
66. Тот факт, что основанная на дате функция сейчас работает, означает, что она будет работать при любой дате.
Даже на 2100-02-31?
67. Год содержит 365 или 366 дней.
Куча календарей, где это может быть не так. Мусульманский, например.
68. За каждой календарной датой располагается последовательно дальнейшая без пропуска.
Переход католиков на григорианский календарь.
69. Приведённая дата и/или показание часов однозначно идентифицируют уникальный момент времени.
Сильно зависит от контекста (см. переходы с юлианского на григорианский).
70. Високосные годы имеют место каждые 4 года.
После 2096-го високосным будет только 2104-й.
71. Зная область/район, можно определить их часовой пояс.
Новосибирск (до 1958-го года) располагался сразу в двух часовых поясах.
72. Зная населённый пункт, можно определить его часовой пояс.
Аналогично.
73. Время идёт с одинаковой скоростью на вершине горы и в самой нижней части долины.
Ну в общем — наверное, синхронизированные атомные часы могут показать разницу.
74. Один час равен следующему во всех системах отсчёта времени.
Високосная секунда.
75. Можно рассчитать, когда будут добавлены високосные секунды.
Не готов комментировать. Вообще этим занимается Международная служба вращения Земли. Есть ли у них надежный алгоритм расчета — не в курсе.
76. Точность типа данных, возвращаемых функцией getCurrentTime(), является той же, что и точность этой функции.
Не готов комментировать
77. Два последовательных вызова функции getCurrentTime() вернут различающиеся результаты.
Високосная секунда?
78. Второй из двух последовательных вызовов функции getCurrentTime() вернёт большее значение.
Високосная секунда?
79. Данное программное обеспечение никогда не будет работать на космическом корабле, облетающем чёрную дыру.
А вот это можно запихать в лицензионное соглашение!
Подвижки часовых поясов в России за последние годы
2. Хорошо, отставляя в сторону исторические курьёзы, разность между двумя часовыми поясами не изменится в будущем.
И они еще могут быть
3. Изменение разности между часовыми поясами будет происходить с выдачей множества предварительных оповещений.
Мне кажется, в примерах не нуждается. И так понятно, что — всяко бывает.
4. Переход на летнее время происходит каждый год в одно и то же время.
СССР переводился, вроде, с воскресенья на понедельник. Сейчас — на выходных.
5. Переход на летнее время происходит в каждом часовом поясе в одно и то же время.
Аналогично.
6. При переходе на летнее время всегда происходит сдвиг на один час.
Недавний перевод часов в России — часть областей уехала на иное количество часов.
7. Количество дней в месяце составляет 28, 29, 30 или 31.
1582 год. У католиков в октябре после 4-го числа сразу настало 15-е.
8. День месяца всегда изменяется последовательно с N на N+1 или на 1 без какого-либо разрыва.
См. предыдущий пункт
9. В каждый момент времени используется только одна календарная система.
Мусульмане и ряд восточных стран одновременно могут пользоваться несколькими календарями.
10. Високосный год имеет место в каждый год, который делится на 4.
1900-й и 2100-й года — невисокосные.
11. Невисокосный год никогда не имеет 29 февраля.
С этим сложности. Я не знаю контрпримеров.
12. Легко сосчитать количество часов и минут, прошедших с какого-то определённого момента времени.
Взять, например, переход Швеции на григорианский календарь. Там мозг сломать можно уже на описании — даже не расчете…
13. Один и тот же месяц содержит одно и то же число дней везде!
Переход на григорианский был различен в разных странах.
14. Время в Unix измеряется только в секундах.
Видимо, имеется в виду, что «реальное» время во время добавления високосной секунды составляет две секунды, когда в Unix фиксируется только одна секунда (соответственно, это может быть чревато для промобъектов, вычисления скорости и так далее).
15. Время в Unix представляет собой количество секунд, начиная с 01 января 1970 года.
Високосные секунды отбрасываются.
16. Субботе всегда предшествует пятница.
Переход через линию перемены дат (ЛПД) в полночь позволит попасть в субботу из четверга. Ну или из субботы.
17. Соседние часовые пояса различаются не более чем на один час (другими словами: мы не должны проверять, что происходит с авиационной электроникой при пролёте над линией перемены даты).
ЛПД
18. Два разных часовых пояса различаются на целое число получасовок.
Непал и Индия. Отличие — 15 минут.
19. Ладно, на целое число четвертей часа.
Не знаю контрпримера
20. Ладно, на секунды, но это будет существенная разница, если мы не учитываем переход на летнее время.
Не знаю контрпримера
21. Если вы создаёте два объекта даты прямо рядом друг с другом, то они будут представлять одно и то же время (фантастический генератор Гейзенберга).
Не понял сути.
22. Можно подождать, когда часы покажут точно ЧЧ: ММ: СС с дискретизацией один раз в секунду.
При високосной секунде часы могут не показать 23:59:60
23. Если процесс идёт «n» секунд, а затем завершается, то приблизительно «n» секунд прошло на системных часах к моменту завершения.
Високосная секунда.
Или в момент перевода часов.
24. Неделя начинается в понедельник.
США — в воскресенье.
25. День начинается утром.
Не знаю контрпримеров.
26. Праздники занимают целое число полных суток.
Не знаю контрпримеров.
27. Выходные дни состоят из субботы и воскресенья.
Переносы выходных дней из-за праздников.
28. Можно установить общий порядок формирования временных меток, который будет полезен за пределами вашей системы.
Не понял сути.
29. Смещение местного времени (относительно универсального синхронизированного времени (UTC)) не изменится в течение рабочего дня.
Перенос часовых поясов круглосуточного производства.
30. Thread.sleep(1000) приостанавливает выполнение на 1000 миллисекунд.
Високосная секунда.
31. Thread.sleep(1000) приостанавливает выполнение на время >= 1000 миллисекунд.
Не знаю контрпримера.
32. Каждая минута содержит 60 секунд.
Високосная секунда
33. Метки времени всегда продвигаются монотонно.
Високосная секунда
34. Среднее время по Гринвичу (GMT) и универсальное синхронизированное время (UTC) представляют один и тот же часовой пояс.
Не знаю контрпримера
35. Великобритания использует среднее время по Гринвичу (GMT).
Перешли на UTC по причине неравномерности GMT из-за неравномерности вращения Земли.
36. Время всегда идёт вперёд.
Физически — не знаю контрпримера. Но местное при пересечении ЛПД может идти и вспять…
37. Разность между текущим моментом времени и моментом времени, отстоящим на одну неделю, всегда равна 7 * 86400 секунд.
Високосная секунда
38. Разность двух меток времени является точной мерой времени, прошедшего между ними.
Високосная секунда
39. 24:12:34 — неправильное время.
Не знаю контрпримера.
40. Каждое целое число теоретически может означать год.
Не понял смысла фразы.
Может, имеется в виду, что минус триллион не имеет смысла в нашей Вселенной?
Нулевой год используется астрономами.
41. При выводе на дисплей даты и времени показываемое время имеет ту же самую вторую часть, что и время, хранимое в памяти.
Не понял, что есть вторая часть. Возможно, имеется в виду сегмент секунд или их доли?
42. Или тот же год.
На время отрисовки (ненулевое) может прийтись новый год.
43. Но, по крайней мере, разность между показываемым и хранимым годом не превышает 2.
Не знаю контрпримеров.
44. Если данные находятся в правильном формате ГГГГ-ММ-ДД, то год содержит четыре цифры.
382-12-01 — первое декабря 382-го года, очевидно, либо должно иметь фильтр на ввод, требующий вбивать 0382, либо обрабатывать и такие варианты.
45. Если происходит слияние двух дат путём заимствования месяца из первой, а дня и/или года — из второй, то дата получается правильной.
Сливаем 20 февраля и 31 января. 31 февраля, мне кажется, еще не случалось.
46. Но это будет работать, только если оба года — високосные.
Аналогично.
47. Если взять опубликованный алгоритм, описанный спецификацией W3C, для добавления некоторой продолжительности к датам, то он будет работать во всех случаях.
Не знаю контрпримера.
48. Стандартная библиотека поддерживает отрицательные годы и годы, превышающие 10000.
Не готов прокомментировать.
49. Часовые пояса всегда различаются на целый час.
Непал-Индия.
50. При преобразовании метки времени, имеющей точность в миллисекундах, во время, имеющее точность в секундах, можно спокойно не учитывать составляющие в миллисекундах.
Не готов комментировать.
51. Можно не учитывать составляющую в миллисекундах, если она менее 0,5.
Не готов комментировать.
52. Год, представленный в виде двух цифр, должен быть в диапазоне 1900-2099.
А может и не быть. И как трактовать 42? Это 1942 или 2042?
53. При синтаксическом анализе времени, даты можно читать числа последовательно (символ за символом) без необходимости возвращаться назад.
Не готов комментировать.
54. При распечатке времени, даты можно писать числа последовательно (символ за символом) без необходимости возвращаться назад.
Не готов комментировать.
55. У вас никогда не будет необходимости выполнять синтаксический анализ примерно такого формата ---12Z или P12Y34M56DT78H90M12.345S.
Не готов комментировать.
56. Имеется только 24 часовых пояса.
Больше. Даже если не учитывать получасовые и четвертьчасовые извращения, а также (не)переход на зимнее, часовых поясов есть от -12:00 до +14:00.
57. Часовые пояса всегда различаются на целое число часов относительно универсального синхронизированного времени (UTC).
Индия-Непал
58. Переход на летнее время везде начинается/заканчивается в один и тот же день.
Не знаю контрпримеров.
59. Переход на летнее время всегда представляет собой сдвиг на 1 час вперёд.
Подвижки поясов в России.
60. Считывание часов клиента и сравнение с UTC является хорошим способом определить часовой пояс клиента.
Не учитывает летнее-зимнее время, да к тому же клиент может иметь непереведенные часы (например, пребывать в командировке в другом часовом поясе).
61. Программно-реализованный стек будет / не будет пытаться автоматически настроиться на часовой пояс / переход на летнее время.
Не готов комментировать.
62. Моя программа используется только внутри предприятия / локально, поэтому мне не надо беспокоиться о часовых поясах.
Ну, если подвижки времени вообще ни на что не влияют, то в ряде очень отдельных случаев — возможно.
Но полагаться на это по умолчанию — не стоит.
63. Мой программно-реализованный стек будет обрабатывать это без необходимости какого-либо моего вмешательства.
Не готов комментировать.
64. Я могу легко сохранить список часовых поясов сам.
После чего опять произойдет нормотворческий зуд у какого-нибудь политика…
65. Все измерения времени на данных часах будут происходить в одной и той же системе отсчёта.
В сильно специальных условиях — возможно. Но надо проверять.
66. Тот факт, что основанная на дате функция сейчас работает, означает, что она будет работать при любой дате.
Даже на 2100-02-31?
67. Год содержит 365 или 366 дней.
Куча календарей, где это может быть не так. Мусульманский, например.
68. За каждой календарной датой располагается последовательно дальнейшая без пропуска.
Переход католиков на григорианский календарь.
69. Приведённая дата и/или показание часов однозначно идентифицируют уникальный момент времени.
Сильно зависит от контекста (см. переходы с юлианского на григорианский).
70. Високосные годы имеют место каждые 4 года.
После 2096-го високосным будет только 2104-й.
71. Зная область/район, можно определить их часовой пояс.
Новосибирск (до 1958-го года) располагался сразу в двух часовых поясах.
72. Зная населённый пункт, можно определить его часовой пояс.
Аналогично.
73. Время идёт с одинаковой скоростью на вершине горы и в самой нижней части долины.
Ну в общем — наверное, синхронизированные атомные часы могут показать разницу.
74. Один час равен следующему во всех системах отсчёта времени.
Високосная секунда.
75. Можно рассчитать, когда будут добавлены високосные секунды.
Не готов комментировать. Вообще этим занимается Международная служба вращения Земли. Есть ли у них надежный алгоритм расчета — не в курсе.
76. Точность типа данных, возвращаемых функцией getCurrentTime(), является той же, что и точность этой функции.
Не готов комментировать
77. Два последовательных вызова функции getCurrentTime() вернут различающиеся результаты.
Високосная секунда?
78. Второй из двух последовательных вызовов функции getCurrentTime() вернёт большее значение.
Високосная секунда?
79. Данное программное обеспечение никогда не будет работать на космическом корабле, облетающем чёрную дыру.
А вот это можно запихать в лицензионное соглашение!
Израиль отличный пример с выходными. они в Пт и Сб. Вс нормальный рабочий день.
> 36. Время всегда идёт вперёд.
Думаю, имеются в виду прыжки времени из-за шаловливых ручек пользователя. Помню, болтал по Skype и одновременно настраивал ntpd. Я отмотал время назад, и в итоге Skype показывал, что я разговариваю 1 000 000 часов. Всё остальное работало, что очень мне понравилось)
Или всем знакомые проблемы с SSL сертификатами, когда из-за кривого локального времени сертификат недействителен.
А, а ещё в *nix может возникнуть time paradox, при попытке удаления файла раньше, чем он был создан. (не проверял, кто сталкивался — буду рад узнать больше)
Думаю, имеются в виду прыжки времени из-за шаловливых ручек пользователя. Помню, болтал по Skype и одновременно настраивал ntpd. Я отмотал время назад, и в итоге Skype показывал, что я разговариваю 1 000 000 часов. Всё остальное работало, что очень мне понравилось)
Или всем знакомые проблемы с SSL сертификатами, когда из-за кривого локального времени сертификат недействителен.
А, а ещё в *nix может возникнуть time paradox, при попытке удаления файла раньше, чем он был создан. (не проверял, кто сталкивался — буду рад узнать больше)
11. Невисокосный год никогда не имеет 29 февраля.
С этим сложности. Я не знаю контрпримеров
Та же Швеция. Из вики:
В Швеции решили отменять високосные дни с 1700 по 1740 годы. В 1700 году был отменён первый високосный день. Потом началась война и про перевод забыли. Таким образом, страна жила по своему собственному шведскому календарю. В 1711 году Карл XII признал это непрактичным и решил вернуться к старому стилю и добавить в феврале 2 дня. Поэтому в Швеции было 30 февраля 1712 года. Лишь в 1753 году был введён новый стиль. При этом после 17 февраля последовало сразу 1 марта.
Прошу прощения, поторопился, 1712 всё таки высокосный. Но 30е февраля тоже интересный пример: )
31. Thread.sleep(1000) приостанавливает выполнение на время >= 1000 миллисекунд.Вики:
Не знаю контрпримера.
Теоретически возможно объявление отрицательной секунды координации, если средние солнечные сутки окажутся короче календарных
36. Время всегда идёт вперёд.Достаточно перехода с летнего времени на обычное?
Физически — не знаю контрпримера. Но местное при пересечении ЛПД может идти и вспять…
31. Thread.sleep(1000) приостанавливает выполнение на время >= 1000 миллисекунд.
Не знаю контрпримера.
Возможно, речь идёт о том, что системное время изменится на >= 1000 миллисекунд за время Thread.Sleep(1000), однако в этот момент может быть, например, переведено время на час назад…
Всё ещё смешнее: sleep(n) действительно может отработать чуть-чуть меньше, чем за n. С чем связано — не разбирался, но видел своими глазами неоднократно.
Почему-то сразу вспоминается, что в Stopwatch, например, есть проверка на то, что результирующее время может оказаться отрицательным — тогда принудительно возвращается 0.
Системный менеджер процессов может работать с некоторыми интервалами. И может разбудить поток и немного раньше.
Может, кто-нибудь кроме ОС, вызывает прерывание таймера? Мы в школе во времена мс-дос таким баловались.
22. Можно подождать, когда часы покажут точно ЧЧ: ММ: СС с дискретизацией один раз в секунду.Мне кажется, причина в том, что выдержать точный шаг дискретизации невозможно. Т.е, если нам нужно засечь время 00:00:01, то велика вероятность перепрыгнуть: 00:00:00.999, а следующий отсчет 00:00:02.000
36. Время всегда идёт вперёд.
77. Два последовательных вызова функции getCurrentTime() вернут различающиеся результаты.
78. Второй из двух последовательных вызовов функции getCurrentTime() вернёт большее значение.
Перевод времени назад.
76. Точность типа данных, возвращаемых функцией getCurrentTime(), является той же, что и точность этой функции.
Системные часы могут не иметь миллисекундной точности.
30. Thread.sleep(1000) приостанавливает выполнение на 1000 миллисекунд.
31. Thread.sleep(1000) приостанавливает выполнение на время >= 1000 миллисекунд.
sleep() может быть прерван через thread.interrupt() или по другим причинам, и поток проснётся раньше. Потоку может не достаться процессорного времени, и он проснётся позже.
34. Среднее время по Гринвичу (GMT) и универсальное синхронизированное время (UTC) представляют один и тот же часовой пояс.
GMT это с летним временем, хотя могу ошибаться.
Наверняка это не всё. Также отмечу, что часовые пояса меняются не только в России. Каждые 2-3 месяца в мире какой-нибудь пояс меняется. см. tzdata.
Вообще, большая часть пунктов решается использованием tzdata, и большая часть из того, что не решается tzdata, — знанием особенностей платформы. Остальные действительно удивляют.
77. Два последовательных вызова функции getCurrentTime() вернут различающиеся результаты.
78. Второй из двух последовательных вызовов функции getCurrentTime() вернёт большее значение.
Перевод времени назад.
76. Точность типа данных, возвращаемых функцией getCurrentTime(), является той же, что и точность этой функции.
Системные часы могут не иметь миллисекундной точности.
30. Thread.sleep(1000) приостанавливает выполнение на 1000 миллисекунд.
31. Thread.sleep(1000) приостанавливает выполнение на время >= 1000 миллисекунд.
sleep() может быть прерван через thread.interrupt() или по другим причинам, и поток проснётся раньше. Потоку может не достаться процессорного времени, и он проснётся позже.
34. Среднее время по Гринвичу (GMT) и универсальное синхронизированное время (UTC) представляют один и тот же часовой пояс.
GMT это с летним временем, хотя могу ошибаться.
Наверняка это не всё. Также отмечу, что часовые пояса меняются не только в России. Каждые 2-3 месяца в мире какой-нибудь пояс меняется. см. tzdata.
Вообще, большая часть пунктов решается использованием tzdata, и большая часть из того, что не решается tzdata, — знанием особенностей платформы. Остальные действительно удивляют.
- Два разных часовых пояса различаются на целое число получасовок.
Непал и Индия. Отличие — 15 минут.- Ладно, на целое число четвертей часа.
Не знаю контрпримера- Ладно, на секунды, но это будет существенная разница, если мы не учитываем переход на летнее время.
Не знаю контрпримера
Думаю, имелся в виду UTC−00:25:21, существовавший до 1916 года в Ирландии. Других часовых поясов с точностью до секунд я не нашел (с точностью до минут был еще UTC−00:44 в Либерии до 1972 года).
22. Можно подождать, когда часы покажут точно ЧЧ: ММ: СС с дискретизацией один раз в секунду.
Я полагаю, проблема в том, что во‐первых, секунда «часов» по разным причинам
может быть короче секунды — к примеру, ntpd синхронизирует системное время,
укорачивая/удлиняя секунду. Либо это отсылка к тому факту, что на не‐realtime
системах подождать в точности одну секунду у вас не выйдет никак, а на realtime
вы всё равно ограничены точностью генератора.
30. Thread.sleep(1000) приостанавливает выполнение на 1000 миллисекунд.
Високосная секунда.
При чём тут она? Нормальный sleep использует другие часы. Дело в том, что
Thread.sleep(1000) на не‐realtime системах (т.е. в абсолютном большинстве
систем) передаст управление ядру, которое радостно загрузит следующий процесс.
И не отдаст управление обратно, пока опять не будет вызван планировщик задач,
и то вам может помешать более приоритетный процесс. При этом планировщику нужно
убедиться, что поток подождал достаточно (т.е. управление ваш поток, скорее
всего, получит только на следующий после 1 000 мс вызов).
31. Thread.sleep(1000) приостанавливает выполнение на время >= 1000
миллисекунд.
Не знаю контрпримера.
В linux NTP использует adjtime(), который влияет, в том числе, и на
CLOCK_MONOTONIC. Обычно когда нужны монотонно возрастающие часы используют
именно их, а не CLOCK_MONOTONIC_RAW. Сильных изменений adjtime не сделает, но
вполне может замедлить часы достатачно, чтобы время было меньше.
Кроме того, я не знаю, как планировщик определяет «достаточно подождал»: одним
из возможных вариантов будет «в результате работы планировщика мат. ожидание
времени в sleep должно быть равно 1 000 мс», что автоматически означает, что
часть процессов должна ждать меньше.
Правда мне не понятно, что здесь делают эти пункты: совершенно определённо, что
Thread.sleep() не имеет отношения к «внешнему» времени.
36. Время всегда идёт вперёд.
Физически — не знаю контрпримера. Но местное при пересечении ЛПД может идти
и вспять…
Учитывая, что Thread.sleep() — это уже детали реализации, предполагаю что
имеется ввиду просто то, что пользователь может внезапно перевести часы.
58. Переход на летнее время везде начинается/заканчивается в один и тот же
день.
Не знаю контрпримеров.
Вы говорили, что «СССР переводился, вроде, с воскресенья на понедельник. Сейчас
— на выходных.» А другие страны с летним временем в тот же период?
60. Считывание часов клиента и сравнение с UTC является хорошим способом
определить часовой пояс клиента.
Не учитывает летнее-зимнее время, да к тому же клиент может иметь
непереведенные часы (например, пребывать в командировке в другом часовом
поясе).
Ещё есть вопрос про «считывание часов»: в linux время хранится в виде UNIX
timestamp и отдельно часовой пояс. Таким образом, в зависимости от способа
считывания, может оказаться, что сравнение с UTC всегда будет укладываться
в пределы погрешности синхронизации часов.
77. Два последовательных вызова функции getCurrentTime() вернут различающиеся
результаты.
Високосная секунда?
Нет. getCurrentTime() может отработать до того, как время изменится.
Время может идти не в перед, если в процессе выполнения приложения, кто-то изменил время.
Например тот же часовой пояс назад на час уехал, или просто запустилась синхронизация с атомными часами в инете и локальное время поправилось на +-несколько секунд
Например тот же часовой пояс назад на час уехал, или просто запустилась синхронизация с атомными часами в инете и локальное время поправилось на +-несколько секунд
Спасибо, и еще тайский календарь со смещением в 543 лет вперед.
29 февраля 1931 года
Если вы про советский революционный календарь, то в табель-календаре на 1931 год 29 февраля отсутствует:
Он же в более читаемом виде:
Источник — Википедия.
Он же в более читаемом виде:
Источник — Википедия.
Внимательно читали?)
| На самом деле указанные дни существовали, но не являлись «днями пятидневок». Календарь являлся табелем в прямом смысле слова, в нём содержались только рабочие дни без праздников/
| Если бы было принято решение, 29 февраля могло бы также не входить в число дней табеля-календаря, тогда табель-календарь остался бы совершенно неизменным для любого года.
| На самом деле указанные дни существовали, но не являлись «днями пятидневок». Календарь являлся табелем в прямом смысле слова, в нём содержались только рабочие дни без праздников/
| Если бы было принято решение, 29 февраля могло бы также не входить в число дней табеля-календаря, тогда табель-календарь остался бы совершенно неизменным для любого года.
Тогда поясните, пожалуйста, такую вещь — я насчитал в табель-календаре 72*5=360 дней.
При этом в табель-календаре не обозначены 22 января, 1 и 2 мая, 7 и 8 ноября. Еще пять.
В сумме — 365.
Вы уверены, что заради 29 февраля сам 1931 год было решено удлиннить на один день, и при этом вообще не упоминать, хотя пять праздничных дней заявлены явно?
При этом в табель-календаре не обозначены 22 января, 1 и 2 мая, 7 и 8 ноября. Еще пять.
В сумме — 365.
Вы уверены, что заради 29 февраля сам 1931 год было решено удлиннить на один день, и при этом вообще не упоминать, хотя пять праздничных дней заявлены явно?
Но вот почему то казусы с рожденными 29 февраля 30 и 31 годов имеют место быть)
Имеют место рассказы о казусах, а сами казусы — а) могут существовать, но объясняться ошибками паспортисток, б) могут не существовать, в) могут существовать и объясняться тем, что 29 февраля в 1930/31-м году было, но не обнаружено документальных подтверждений их существования, г) могут существуют, просто я не смог найти их документированными.
Как по мне, бритва Оккама оставляет варианты а и б.
Если вы можете показать документы с такой датой — с удовольствием ознакомлюсь.
Как по мне, бритва Оккама оставляет варианты а и б.
Если вы можете показать документы с такой датой — с удовольствием ознакомлюсь.
http://lists.memo.ru/index16.htm (ищи Попов Сергей Александрович 1881)
https://people.onliner.by/2013/09/17/belorus-rodilsya-30-fevralya (возможно утка)
ну и про Камчатский УФМС где-то ниже написано.
https://people.onliner.by/2013/09/17/belorus-rodilsya-30-fevralya (возможно утка)
ну и про Камчатский УФМС где-то ниже написано.
1) Я не вижу документов.
На сайте записано со слов воронежского «Мемориала». Варианты фактического источника записи: а) ошибка в бумажном документе, б) ошибка сканирования, в) ошибка распознавания, г) ошибка программиста, писавшего скрипт генерации жертв политических репрессий, д) ошибка при переносе на lists.memo.ru.
2) ситуация еще краше:
Вообще не понимаю, почему этот курьез может служить доказательством.
Вот вам еще несколько табель-календарей. Покажите, пожалуйста, 29 или тем паче 30 февраля.
На сайте записано со слов воронежского «Мемориала». Варианты фактического источника записи: а) ошибка в бумажном документе, б) ошибка сканирования, в) ошибка распознавания, г) ошибка программиста, писавшего скрипт генерации жертв политических репрессий, д) ошибка при переносе на lists.memo.ru.
2) ситуация еще краше:
В сельсовете кумекали, спрашивали у соседей. В итоге решили записать: 30 февраля. Так и живет Максим Сойко с несуществующей датой в паспорте.
Вообще не понимаю, почему этот курьез может служить доказательством.
Вот вам еще несколько табель-календарей. Покажите, пожалуйста, 29 или тем паче 30 февраля.
Если вы можете показать документы с такой датой — с удовольствием ознакомлюсь.
Вот, например: (найдено здесь)
Идем по ссылке.
Там идем и внимательно читаем:
Там идем и внимательно читаем:
История с необычной датой рождения для тех лет вполне типична: 6-летний мальчик, он пришел к старшине и не мог точно сказать, когда родился. В сельсовете кумекали, спрашивали у соседей. В итоге решили записать: 30 февраля. Так и живет Максим Сойко с несуществующей датой в паспорте. Сколько раз во всяких документах спотыкались о необычную запись.
Во-первых — по-вашему в сельсовете не знали что 30-го февраля не бывает? Потроллить пацана решили?
Во-вторых — есть как минимум еще один подобный случай (ниже мой коментарий о судебном решении по поводу пенсионерки с датой рождения 29-го февраля 1930). Суд признал, что ее свидетельство о рождении с такой датой действительно, и предписал УФМС внести изменения в свое ПО, чтобы оно считало дату 29.02.1930 валидной. Что, в контест статьи — о том что программы должны быть готовы к таким неожиданностям — вполне укладывается.
Во-вторых — есть как минимум еще один подобный случай (ниже мой коментарий о судебном решении по поводу пенсионерки с датой рождения 29-го февраля 1930). Суд признал, что ее свидетельство о рождении с такой датой действительно, и предписал УФМС внести изменения в свое ПО, чтобы оно считало дату 29.02.1930 валидной. Что, в контест статьи — о том что программы должны быть готовы к таким неожиданностям — вполне укладывается.
Внимательно почитал статью Вики:
А вариант с февральскими извращениями — это теоретический вариант:
Фактический вариант месяца с пятидневной неделей
Все месяцы сохраняли привычное число дней
А вариант с февральскими извращениями — это теоретический вариант:
Теоретический вариант месяца с пятидневной неделей
Во многих источниках указывается, что каждый месяц состоял из тридцати дней и, таким образом, в Советском Союзе в 1930 и 1931 годах существовало 30 февраля. В действительности это предложение было отвергнуто.
Оставшиеся пять или шесть дней предлагалось объявить так называемыми «безмесячными каникулами», они не входили ни в один месяц и ни в одну неделю, зато имели собственные имена:
День Ленина, следовавший за 30 января (по другим источникам — после 22 января)
Дни труда, 2 дня, следовавшие за 30 апреля
Индустриальные дни, 2 дня, следовавшие за 7 ноября
в високосные годы добавочный високосный день; следовал за 30 февраля
Этот не воплотившийся в жизнь проект очень похож на подобный же проект постоянного (стабильного) календаря.
25. Если имеется ввиду световой день, то полярная ночь.
26. Час Земли считается праздником?
34. разница между UTC и GMT может доходить до 0,9с
26. Час Земли считается праздником?
34. разница между UTC и GMT может доходить до 0,9с
7. Количество дней в месяце составляет 28, 29, 30 или 31.
1582 год. У католиков в октябре после 4-го числа сразу настало 15-е.
Поменялся календарь? Вы считаете нормальным измерять начало интервала по одной системе а конец по другой?
9. В каждый момент времени используется только одна календарная система.
Мусульмане и ряд восточных стран одновременно могут пользоваться несколькими календарями.
Аналогично
11. Невисокосный год никогда не имеет 29 февраля.
С этим сложности. Я не знаю контрпримеров.
Очевидно, опять намекают на другие календари. С учетом того, что предыдущее заблуждение явно про григорианский календарь (общепризнанный современный то бишь), то 0 заблуждением во всем этом списке следует назвать «при обсуждении темы времени все участники говорят об одном и том же и только об одном календаре». В противном случае вся эта дискуссия похоже на беседу шизофреников.
44. Если данные находятся в правильном формате ГГГГ-ММ-ДД, то год содержит четыре цифры.
382-12-01 — первое декабря 382-го года, очевидно, либо должно иметь фильтр на ввод, требующий вбивать 0382, либо обрабатывать и такие варианты.
Похоже, имеется ввиду наоборот, если приходит 0382-12-01, то после преобразования Str->Int->Str без паддингов для года получим 3-хзначное число. Формат ГГГГ-ММ-ДД уже предполагает, что для года требуют ввести 4 цифры.
67. Год содержит 365 или 366 дней.
Куча календарей, где это может быть не так. Мусульманский, например.
Все-таки пора определиться, один календарь мы рассматриваем или все, в том числе и те, которые придумают в будущем.
25. День начинается утром.
Возможно имеется в виду астрономический день — он начинается в полдень.
https://en.wikipedia.org/wiki/Astronomical_day
Возможно имеется в виду астрономический день — он начинается в полдень.
https://en.wikipedia.org/wiki/Astronomical_day
39. 24:12:34 — неправильное время
В оригинальной статье на реддите приводили пример: ТВ-расписание в японии. Поздние программы считаются частью прошлого дня. Вот расписание, где встречаются времена вида 27:04.
26. Праздники занимают целое число полных суток.
антипример: Рамандан начинается с восхода солнца + месяц и до заката крайнего дня.
Пасха с вечерней службы (примерно в 16-17часов) и +39 дней
антипример: Рамандан начинается с восхода солнца + месяц и до заката крайнего дня.
Пасха с вечерней службы (примерно в 16-17часов) и +39 дней
11. Невисокосный год никогда не имеет 29 февраля.
С этим сложности. Я не знаю контрпримеров.
Например: (источник)
В Камчатском крае суд обязал миграционную службу заменить паспорт женщине, в котором из-за сбоя программы ФМС, не обнаруживший в 1930 году день 29 февраля, датой рождения было указано «00.00.1930»
Как пояснили в суде, 1930 год не был високосным, но, несмотря на это, 29 февраля тогда в календаре имелось, отмечает «Интерфакс». В этот год СССР жил по Советскому революционному календарю, который просуществовал лишь несколько лет.
39. 24:12:34 — неправильное время.
Не знаю контрпримера.
В солнечных сутках может быть больше 24 часов
>7. Количество дней в месяце составляет 28, 29, 30 или 31.
> 1582 год. У католиков в октябре после 4-го числа сразу настало 15-е.
И сейчас бывает. Например 13-й месяц в Коптском календаре длится 5 или 6 дней.
9. В каждый момент времени используется только одна календарная система.
> Мусульмане и ряд восточных стран одновременно могут пользоваться несколькими календарями.
В Непале вообще 5--6.
10. Високосный год имеет место в каждый год, который делится на 4.
В Григорианском каждый год N, при N mod 400 = {100,200,300} невискосный.
11. Невисокосный год никогда не имеет 29 февраля.
Напрмер, Календарь Армелина и другие стабильные календари
19. Ладно, на целое число четвертей часа.
Сейчас наверное нет таких примеров. Но, например, в процессе перехода к поясным временам, растянувшимся на полвека было:
В Либерии до 1972 время было UTC +44:30.
24. Неделя начинается в понедельник.
>США — в воскресенье.
В Иране в субботу
25. День начинается утром.
> Не знаю контрпримеров.
Что такое день и что такое утро? Утро — это восход или конец (астрономических, навигационных, гражданских) сумерек?
А если день Полярный? А если Полярная ночь, то определяется ли день?
27. Выходные дни состоят из субботы и воскресенья.
В Иране только пятница
28. Можно установить общий порядок формирования временных меток, который будет полезен за пределами вашей системы.
Думаю нельзя. В Иранском календаре циклы по 33 года, но иногда назначаются по 29 или 37 лет.
30. Thread.sleep(1000) приостанавливает выполнение на 1000 миллисекунд.
Високосная секунда.
Вероятно не в этом дело. О ВС системные часы не знают. Скорее точность «тиков» процессора.
31. Thread.sleep(1000) приостанавливает выполнение на время >= 1000 миллисекунд.
Наверное 999.51 вполне возможно.
36. Время всегда идёт вперёд.
> Физически — не знаю контрпримера. Но местное при пересечении ЛПД может идти и вспять…
И не только ЛДП. Просто большинство скачков на запад из пояса в пояс.
Аналогично, астрономическое время при достаточно быстром перемещении на запад. А у полюсов и при небыстром.
39. 24:12:34 — неправильное время.
JS так не считает. В консоли, например:
s = new Date() Wed Oct 26 2016 14:58:14 GMT+0300 s.setHours(0,0,0); s Wed Oct 26 2016 00:00:00 GMT+0300 s.setHours(0,0,90); s Wed Oct 26 2016 00:01:30 GMT+0300 s.setHours(0,0,90); s Wed Oct 26 2016 00:01:30 GMT+0300 s.setHours(0,70,90); s Wed Oct 26 2016 01:11:30 GMT+0300 s.setHours(0,70,90); s Wed Oct 26 2016 01:11:30 GMT+0300 s.setHours(0,70,90); s Wed Oct 26 2016 01:11:30 GMT+0300 s.setHours(23,70,90); s Thu Oct 27 2016 00:11:30 GMT+0300 s.setHours(25,70,90); s Fri Oct 28 2016 02:11:30 GMT+0300 s.setHours(25,70,90); s Sat Oct 29 2016 02:11:30 GMT+0300
Недаром тут некоторые вводы повторены два раза. Дело в том, что если 3600*h + 60*m + s не прывышает 86400, то мы получем «корректную» установку даты с учётом переполенния
минут и секунд, а в ином случае при повторном введении значений у нас щёлкает и день.
О том какой качественный это багогенератор, можно долго рассуждать.
50. При преобразовании метки времени, имеющей точность в миллисекундах, во время, имеющее точность в секундах, можно спокойно не учитывать составляющие в миллисекундах.
не учитвать, это просто отбрасывать (floor), но лучеше всё-таки округлять иначе целевое время будет иметь ощику выше 0.5 сек.
51. Можно не учитывать составляющую в миллисекундах, если она менее 0,5.
Если не учесть (особенно отбросив как выше), то при переходе в Новый Год (месяц, час) можно получить казус (скрыть различия или выявить его при отсутсвии).
58. Переход на летнее время везде начинается/заканчивается в один и тот же день.
Теоретически, если в одной стране есть пояса отличающиеся не на целое число часoв, то можно скакнуть пр переходе.
Хороший пример Австалия с поясами: +8:45, +9:3о, +1о: оо (и ещё там острова есть +5: оо, +6:3o, +1о:3о)
70. Високосные годы имеют место каждые 4 года.
В Григорианском каждый год N, при N mod 400 = {100,200,300} невискосный.
В Иране обычно циклы по 33 года (вискосные там N mod 33 = {1, 5, 9, 13, 17, 22, 26 или 30} )
71. Зная область/район, можно определить их часовой пояс.
Антарктида. Китай. Гренландия.
73. Время идёт с одинаковой скоростью на вершине горы и в самой нижней части долины.
> Ну в общем — наверное, синхронизированные атомные часы могут показать разницу.
Это уже какая-то софистика. Что такое скорость времени? dt/dt? В принципе астрономическое время можно сказать что идёт по разному, если скорость определить как dt/dx [c/м].
Тогда это ещё и от широты зависит.
79. Данное программное обеспечение никогда не будет работать на космическом корабле, облетающем чёрную дыру.
>А вот это можно запихать в лицензионное соглашение!
В целом ПО, вращаясь вместе с солнечной системой вокруг центра галактики, вращается вокруг ЧД.
То же самое по п. 7 в Советской России было в 1918: после 31 января сразу наступило 14 февраля (перешли на григорианский календарь), вследствие чего есть даже шутка, что «с 1 по 13 февраля на территории РСФСР никто не рождался, не умирал и вообще не произошло никаких событий»
UFO just landed and posted this here
11. Невисокосный год никогда не имеет 29 февраля.
С этим сложности. Я не знаю контрпримеров.
В 1930 и 1931 в СССР из-за введения советского революционного календаря AKA пятидневки
Я уже приводил в https://m.habr.com/ru/post/313274/comments/#comment_9882714 найденные мной табель-календари за 30-31 года.
Я там не обнаружил ни единого 29 февраля.
Склонен думать, что это городская легенда, не подтверждающая фактически.
25. День начинается утром.
В религиозных календарях мусульман и иудеев день начинается с заходом солнца.
Перевод первого поста, если кто не видел.
Навевает ностальгию. Тот самый момент, когда ты узнал, что в сутках не всегда 24 часа.
Для понимания многих пунктов рекомендую запустить в терминале
cal 09 1752
UFO just landed and posted this here
Они в этом году приняли григорианский календарь, а две недели — смещение от предыдущего календаря
Т.е. первые 2 дня — от одного календаря, а последующие дни — от другого. И общего между календарями только название месяцев и похожее количество дней в каждом из них. Неужели никто не находит это странным?
Это неудобно и не добавляет изящества в систему измерения времени, но что в этом странного?
Ну… это как если бы, например, чертили вы в какой-нибудь CAD системе дом, и вдруг посередине документа перешли с дюймов на миллиметры. Хотите, пожалуйста — используйте и дюймы и миллиметры, но на разных чертежах. Зачем их смешивать на одном?
Также и с датой. Зачем извращаться и пытаться в одной системе слепить два разных календаря? Вот, например, до 14 сентября 1752 года григорианского календаря было 13 сентября 1752 григорианского календаря. Ну и что, что в тот день этим календарем не пользовались? Это должно на него влиять как-то что ли?
Вообще, при близости таких дат нельзя говорить "1752 год", нужно уточнять, в каком календаре. Просто по умолчанию предполагается какой-то (например, григорианский). Аналогично, когда вы говорите "в 90-х", предполагается 20-й век (т.е. 1990). Если вы имеете ввиду 1890 или 2090, вы же не будите говорить "в 90-х", если конечно хотите, что вас поняли? Почему с календарем иначе?
Ну, время одно, тут не получится не смешивать. Говорят, бог создал мир за шесть дней всего, так как у него не было проблемы обратной совместимости. :)
Что мы будем прошлое по-новому считать, что по-старому, нужно будет уточнять календарь, иначе даты в текстах того времени не перевести.
Да, некрасиво с календарями вышло. Дни по-дурацки распределены. В году нецелое число дней. И високосная секунда эта. И неравномерность вращения Земли, когда любой просто подняв камень замедляет ее обращение вокруг оси. Но вот как-то привыкли.
Ну, время одно, тут не получится не смешивать.
Что значит не получится? В коде программ очень даже получится. Просто нужно четко помнить, что у нас есть несколько календарей и не пытаться создать один GOD-календарь, который будет покрывать все возможные случаи. Получаете странную дату от оператора при вводе в программу? Уточните, что за календарь.
Что мы будем прошлое по-новому считать, что по-старому, нужно будет уточнять календарь, иначе даты в текстах того времени не перевести.
Зачем подгонять календарь под даты? Календарь — по определению система счета дней в какими-то правилами. Разные календари — разные правила. Не проще ли использовать правильный календарь для дат "того времени"? Зачем тащить это легаси в современность, делая его еще более хрупким?
Получаете странную дату от оператора
Это здорово, когда у вас 27 кислева 5750 года, которое есть только у евреев. Но многие календари мало того что используют одинаковые названия, так ещё и использовались одновременно друг с другом и/или в одной и той же стране. Скажем, 4 февраля 1900 года — это по юлианскому или грегорианскому календарю? Или упоминавшееся выше 2 февраля 1931 — по одному из этих двух или советскому революционному?
Переход на григорианский календарь съел.
В этот год «В Великобритании и её североамериканских колониях принят Григорианский календарь.»
Википедия(с)
Википедия(с)
Бог напевал песню про третье сентября, и пропел припев «я календарь переверну...» 11 раз.
И что самое интересное, вывод этого календаря верен лишь для Британской Империи
ncal 02 1918
Четверть проблем — из-за существования часовых поясов. Я убежден, что заблуждением является сама необходимость их существования. Кто-то может внятно объяснить, зачем нужны часовые пояса? Какая разница, во сколько у меня восходит солнце — в 07:00, в 01:00 или в 19:00, если это просто цифра?
Лично я перешел на UTC еще в феврале и с тех пор не заметил ни одной сложности, разве что пришлось научиться мгновенно прибавлять местный часовой пояс, чтобы отвечать на вопрос «который час». Назначать межконтинентальные звонки проще — сразу понятно, через сколько часов он будет проведен. Путешествовать проще — сразу понятно, сколько времени ты провел в пути.
Тогда в чем смысл-то, кроме «тут так принято»? Проще определять время суток на другом конце земного шара, что можно сделать и живя по UTC, примерно запомнив часовые пояса? 20 заблуждений из 79 — великоватая цена за такое ничтожное преимущество.
Лично я перешел на UTC еще в феврале и с тех пор не заметил ни одной сложности, разве что пришлось научиться мгновенно прибавлять местный часовой пояс, чтобы отвечать на вопрос «который час». Назначать межконтинентальные звонки проще — сразу понятно, через сколько часов он будет проведен. Путешествовать проще — сразу понятно, сколько времени ты провел в пути.
Тогда в чем смысл-то, кроме «тут так принято»? Проще определять время суток на другом конце земного шара, что можно сделать и живя по UTC, примерно запомнив часовые пояса? 20 заблуждений из 79 — великоватая цена за такое ничтожное преимущество.
а как быть с летним временем? Переклеивать каждые полгода наклейки с надпись работаю с ХХ до YY?
А в чем проблема с переклеиванием? Да хоть каждый день в разное время, особенно если в календарь забить в телефон, я бы видел сразу во сколько завтра надо быть на работе.
вообще идея — вместо того, что бы сделать адаптивным КЗОТ и т.п законодательство к смене сезонов — начать играться с «системным временем государства» — глубоко порочна. Но законотворцы во всех временах и странах похоже чем-то схожи (с нашими)
Объявление на магазине вместо режимки:
Свет горит — работаем
Свет не горит — не работаем
Свет горит — работаем
Свет не горит — не работаем
Во-первых, потому что подавляющее большинство взаимодействий у подавляющего большинства людей происходят в пределах одного часового пояса и их проблемы перевода времени не волнуют. Некоторые организации (РЖД, например) используют московское время по всей стране, но таких меньшинство.
Во-вторых, при использовании единого времени по всей планете теряется связь между календарным и астрономическим временем. В текущей системе в умеренных широтах в 12:00 Солнце не обязательно в высшей точке, но оно хотя бы точно выше горизонта, а рассвет всегда где-то между диапазоне 3 и 10 часами. ИМХО, запоминать, что в Москве световой день летом с 9 до 2 UTC, а в Иркутске примерно с 13 до 8 — было бы куда большим геммороем.
Во-вторых, при использовании единого времени по всей планете теряется связь между календарным и астрономическим временем. В текущей системе в умеренных широтах в 12:00 Солнце не обязательно в высшей точке, но оно хотя бы точно выше горизонта, а рассвет всегда где-то между диапазоне 3 и 10 часами. ИМХО, запоминать, что в Москве световой день летом с 9 до 2 UTC, а в Иркутске примерно с 13 до 8 — было бы куда большим геммороем.
ну как бы близь серевного пояса, рассветы и закаты чертовски сильно зависят от времени года, и люди же как-то там живут. (в скандинавии например).
Ну, чаще всего нужно знать, какое время суток «там» или сейчас, или в будущем, но относительно текущего часового пояса. А для этого нужно знать или удаленное местное время или их часовой пояс. Если нужно гуглить местное время — можно и погуглить, какое там астрономическое время. Если знать какой часовой пояс — живя по UTC будет еще проще прикинуть относительное астрономическое время, потому что не придется отнимать свой часовой пояс. То есть, часовые пояса должны существовать, но лишь для таких вот калькуляций и не более, автоматическое их применение и бессмысленно, и приводит к ошибкам. Если у организаций нет проблем с жизнью в пределах одного часового пояса — может и у всего мира не будет? :)
Это внесет другие проблемы. Есть законы, которые привязываются к локальному времени. Например, в одной из статей КОАП сказанно, что нельзя шуметь в период с 22:00 до 06:00. То же самое с ограничением на продажу алкоголя после 23:00. Что бы поддерживать такие законы при едином времени, то придется для каждого субъекта указывать свое временное смещение, которым сейчас, и является часовой пояс.
Я, конечно, придираюсь, но все эти мифы касаются календаря, а не времени. Того, как мы выражаем ход времени, а не как оно идёт. Эти вопросы периодически поднимаются и уже не обладают новизной.
Но вот если бы кто-то собрал материал относительно мифов и действительности самого ВРЕМЕНИ, а не календаря, статья получилась бы чрезвычайно любопытной. Насколько я знаю, специалисты (гео)распределённых систем могут целлое эссе посвятить природе времени. И статей научных уже написано достаточно много на эту тему. Я прям даже не знаю, кто произвёл больший объём исследований природы времени — специалисты информатики, или теоретические физики.
Но вот если бы кто-то собрал материал относительно мифов и действительности самого ВРЕМЕНИ, а не календаря, статья получилась бы чрезвычайно любопытной. Насколько я знаю, специалисты (гео)распределённых систем могут целлое эссе посвятить природе времени. И статей научных уже написано достаточно много на эту тему. Я прям даже не знаю, кто произвёл больший объём исследований природы времени — специалисты информатики, или теоретические физики.
Очень интересно, но хотелось бы по каждому пункту почитать кейс.
79. Данное программное обеспечение никогда НЕ будет работать на космическом корабле, облетающем чёрную дыру.
24. Неделя начинается в понедельник.
Который начинается в субботу.
Для большей половины заблуждений, моя фантазия упорно отказывается представит ситуацию при которой заблуждение проявилось и была выявлена проблема…
Турция, например, иногда совершает переход на летнее время когда пр-во решит, и порой это может быть с лагом неделя туда-сюда.
Поэтому, в общем случае «таблеткой» будет использовать всегда и везде внутри системы использовать UTC0, а при отдаче времени — преобразовывать его автоматическки через TZ, в TZ хрянится не только отклонение часового пояса, но и история изменения этих поясов, поэтому конвертация прошлого времени из UTC -> в LocalTZ — должна быть корректной (если вы используете современные либы/средства системы).
И наоборот, когда забираете локальные данные времени от пользователя преобразуете обратно в UTC, вот и всё. Операции между двумя временными параметрами соответственно только UTC<->UTC
Поэтому, в общем случае «таблеткой» будет использовать всегда и везде внутри системы использовать UTC0, а при отдаче времени — преобразовывать его автоматическки через TZ, в TZ хрянится не только отклонение часового пояса, но и история изменения этих поясов, поэтому конвертация прошлого времени из UTC -> в LocalTZ — должна быть корректной (если вы используете современные либы/средства системы).
И наоборот, когда забираете локальные данные времени от пользователя преобразуете обратно в UTC, вот и всё. Операции между двумя временными параметрами соответственно только UTC<->UTC
И, пользуясь этой схемой, попробуйте запланировать событие, которое должно произойти в 5 часов по местному времени через полгода (а лучше — в период лага принятия решения о переводе часов).
Извините, за «некрокоммент», но это сделать в принципе нельзя.
А точнее, должно быть сделано так:
Вы планируете в любом случае в UTC.
Дату будущего вы конвертируете в UTC в соответствии с тем стандартом по переводу времени, что действует. Если у вас нормальная библиотека работы со временем — то она конвертирует прозрачно с учётом перевода стрелок не только по текущему стандарту для страны, но и с учетом истории изменений этих стандартов если вы конвертируете прошлое время.
Вы в любом случае не знаете изменят этот стандарт или нет. И когда вас об этом оповестят. Пример Турции недавних лет, когда они перевели часы, не сообщив об изменении стандарта в консорциум — и вызвал сбой часов в «импортных» устройствах.
В другом случае, если вам так тонко надо отслеживать — то ловите событие «изменение стандарта» — оно фиксируется в базе TZ — Там есть история всех изменений именно стандарта у каждой страны.
Если вам пришло такое событие — то пересчитайте снова будущие 5 часов в локальном времени в UTC, и получите новое UTC, которое станет акутальным.
Поэтому, если кто-то делаетнеправильный мёд придумывает регламент перевода часов на ходу и не оповещает международную систему времени об этом — то сам виноват, не в хрустальный же шар смотреть?
Поэтому опираемся на UTC, а куда уплывают по UTC страны, которые хотят так вертеть своей «палатой мер и весов», как бы сами виноваты. К слову их не так много — в их числе Турция, Россия (которая к слову, все же присылала апдейты временно зоны до перевода часов), и еще пара-тройка стран — не помню.
А точнее, должно быть сделано так:
Вы планируете в любом случае в UTC.
Дату будущего вы конвертируете в UTC в соответствии с тем стандартом по переводу времени, что действует. Если у вас нормальная библиотека работы со временем — то она конвертирует прозрачно с учётом перевода стрелок не только по текущему стандарту для страны, но и с учетом истории изменений этих стандартов если вы конвертируете прошлое время.
Вы в любом случае не знаете изменят этот стандарт или нет. И когда вас об этом оповестят. Пример Турции недавних лет, когда они перевели часы, не сообщив об изменении стандарта в консорциум — и вызвал сбой часов в «импортных» устройствах.
В другом случае, если вам так тонко надо отслеживать — то ловите событие «изменение стандарта» — оно фиксируется в базе TZ — Там есть история всех изменений именно стандарта у каждой страны.
Если вам пришло такое событие — то пересчитайте снова будущие 5 часов в локальном времени в UTC, и получите новое UTC, которое станет акутальным.
Поэтому, если кто-то делает
Поэтому опираемся на UTC, а куда уплывают по UTC страны, которые хотят так вертеть своей «палатой мер и весов», как бы сами виноваты. К слову их не так много — в их числе Турция, Россия (которая к слову, все же присылала апдейты временно зоны до перевода часов), и еще пара-тройка стран — не помню.
Так я вам специально такой кейс предложил, который действительно крайне плохо ложится на схему с хранением в UTC. В нём пользователь хочет событие в его локальном времени, поэтому в его локальном времени его лучше и хранить. Особенно если событие регулярное, типа «каждый вторник в 9 часов вечера напомнить, что пока включить телек и посмотреть новую серию любимого сериала».
Во время переходов на летнее зимнее нужно хитро просчитывать тарификацию.
А то получается, что раз в году в одном дне 23 часа, а во втором 25.
И если считать в лоб EndDatatTime- StartDataTime, то легко можно добавить 1 час разговора, или на оборот, получить, что абонент наговорил -50 минут.
А то получается, что раз в году в одном дне 23 часа, а во втором 25.
И если считать в лоб EndDatatTime- StartDataTime, то легко можно добавить 1 час разговора, или на оборот, получить, что абонент наговорил -50 минут.
Имхо, многие проблемы происходят от того, что представление данных используется как модель. Календарная система или часовой пояс это параметры представления некоторого момента во времени. При работе с разными представлениями нужно приводить их к какому-то общему виду. Unixtime это хорошая идея, но високосные секунды немного ломают картину.
Мне кажется, было бы неплохо сделать более глобальную систему отсчета, например SST (Solar System Time), в которой значение будет увеличиваться на 1 каждую атомную секунду независимо от вращения Земли. Начальное значение установить в примерный возраст Солнечной системы. Все электронные системы могли бы вести отсчет именно в ней. Для всех событий прошлого или будущего можно задать точный момент на этой шкале. Для конвертации в земное время и обратно необходима таблица високосных секунд и часовой пояс, ну и григорианский календарь по умолчанию. Таким образом, будет универсальная однозначная неубывающая система отсчета времени.
Мне кажется, было бы неплохо сделать более глобальную систему отсчета, например SST (Solar System Time), в которой значение будет увеличиваться на 1 каждую атомную секунду независимо от вращения Земли. Начальное значение установить в примерный возраст Солнечной системы. Все электронные системы могли бы вести отсчет именно в ней. Для всех событий прошлого или будущего можно задать точный момент на этой шкале. Для конвертации в земное время и обратно необходима таблица високосных секунд и часовой пояс, ну и григорианский календарь по умолчанию. Таким образом, будет универсальная однозначная неубывающая система отсчета времени.
Sign up to leave a comment.
Заблуждения большинства программистов относительно «времени»