Омани більшості програмістів щодо «часу»

Багато днів тому я вирішив записати деякі спостереження, що сформувалися поки, в останні роки, я займався тестуванням. Розглядаючи області, які отримують найбільшу віддачу від тестування я зрозумів, що у мене накопичилося багато конкретних думок про те, як ми — програмісти — схильні недбало поводитися з поняттям «час» у програмуванні.

Тоді я написав пост «Помилки програмістів щодо „часу“», в якому вказав 34 хибні уявлення та помилки, що відносяться як до календарному, так і до системного часу. З більшістю з них я зіткнувся сам, займаючись дебаггингом програм (як робітників, так і тестових).



Багато із зазначених помилкових уявлень були моїми власними. зокрема, «позначки часу завжди в секундах з початку епохи» і «тривалість однієї хвилини на системному годиннику завжди близька до тривалості однієї хвилини фізичного часу». Я все життя буду з болем згадувати про своїй помилці в цих двох випадках! Але, звичайно, безсумнівно — я не єдиний, хто зіткнувся з такими проблемами (або ненавмисно створив їх). Багато людей відгукнулися і поділилися аналогічним досвідом.
ОНОВЛЕНО: хотів би щиро подякувати всім, хто брав участь у обговоренні цього поста. Я прочитав кожен коментар і дізнався про різні кумедні штуки, таких як, наприклад, річний нуль і міжнародне атомне час.
Хотів би висловити величезну подяку всім, хто вніс свій внесок в обговорення на BoingBoing, Hacker News, Reddit MetaFilter і Twitter, і поділився своїм незвичайним досвідом з «часом» в програмуванні. У цій приблизно тисячі відповідей було багато пропозицій продовжити список «помилок».

Насамперед, було відзначено відсутність помилкового припущення, що «час завжди рухається вперед», як зазначив Technomancy та багато інших. Я отримав задоволення, читаючи всі пропозиції в список. Коли я закінчив читати, то зрозумів, що, загалом і в цілому, вони являють собою просто інший пост в блозі. Тому я зібрав всі ваші пропозиції в один пост і нижче уявляю його.



Всі ці припущення — невірні
Всі нижче наведені припущення «за часом» були запропоновані учасниками обговорення початкового поста. Кожен учасник зазначений в кінці статті.

1. Різниця між двома часовими поясами буде залишатися постійною.
2. Добре, відставляючи вбік історичні курйози, різниця між двома часовими поясами не зміниться в майбутньому.
3. Зміна різниці між часовими поясами буде відбуватися з видачею безлічі попередніх повідомлень.
4. Перехід на літній час відбувається щороку в один і той же час.
5. Перехід на літній час відбувається в кожному часовому поясі в один і той же час.
6. При переході на літній час завжди відбувається зсув на одну годину.
7. Кількість днів в місяці складає 28, 29, 30 або 31.
8. День місяця завжди змінюється послідовно з N на N+1, або 1 без будь-якого розриву.
9. У кожен момент часу використовується тільки одна календарна система.
10. Високосний рік має місце в кожен рік, який ділиться на 4.
11. Невисокосний рік ніколи не має 29 лютого.
12. Легко порахувати кількість годин і хвилин, що пройшли з якогось певного моменту часу.
13. Один і той же місяць містить одне і те ж число днів скрізь!
14. Час в Unix вимірюється в секундах.
15. Час в Unix являє собою кількість секунд, починаючи з 01 січня 1970 року.
16. Суботи завжди передує п'ятниця.
17. Сусідні часові пояси відрізняються не більше ніж на одну годину (іншими словами: ми не повинні перевіряти, що відбувається з авіаційної електронікою при прольоті над лінією зміни дат).
18. Два різних часових пояси розрізняються на ціле число получасовок.
19. Гаразд, на ціле число чвертей години.
20. Гаразд, на секунди, але це буде суттєва різниця, якщо ми не враховуємо перехід на літній час.
21. Якщо ви створюєте два об'єкта дати прямо поруч один з одним, то вони будуть представляти один і той же час (фантастичний генератор Гейзенберга).
22. Можна почекати, коли годинник покажуть точно ЧЧ: ММ: СС з дискретизацією один раз в секунду.
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).
36. Час завжди йде вперед.
37. Різниця між поточним моментом часу і моментом часу, отстоящим на один тиждень, завжди дорівнює 7 * 86400 секунд.
38. Різниця двох міток часу є точною мірою часу, що пройшов між ними.
39. 24:12:34 — неправильний час.
40. Кожне ціле число теоретично може означати рік.
41. При виведення на дисплей дати і часу показується час має ту ж саму другу частину, що і час, збережене в пам'яті.
42. Або той же рік.
43. Але, принаймні, різниця між показуваних і збереженим роком не перевищує 2.
44. Якщо дані знаходяться в правильному форматі РРРР-ММ-ДД, то рік містить чотири цифри.
45. Якщо відбувається злиття двох дат шляхом запозичення місяця з першої, а дня і/або року — з другої, то дата виходить правильною.
46. Але це буде працювати, тільки якщо обидва роки — високосні.
47. Якщо взяти опублікований алгоритм, описаний специфікації W3C, для додавання певної тривалості до дат, то він буде працювати у всіх випадках.
48. Стандартна бібліотека підтримує негативні роки, що перевищують 10000.
49. Часові пояси завжди розрізняються на цілу годину.
50. При перетворенні мітки часу, що має точність в мілісекундах, під час, що має точність в секундах, можна спокійно не враховувати складові в мілісекундах.
51. Можна не враховувати складову в мілісекундах, якщо вона менше 0,5.
52. Рік, представлений у вигляді двох цифр, повинен бути в діапазоні 1900-2099.
53. При синтаксичному аналізі часу, дати можна читати числа послідовно (символ за символом) без необхідності повертатися назад.
54. При роздруківці часу, дати можна писати числа послідовно (символ за символом) без необхідності повертатися назад.
55. У вас ніколи не буде необхідності виконувати синтаксичний аналіз приблизно такого формату ---12Z або P12Y34M56DT78H90M12.345S.
56. Є тільки 24 часових пояси.
57. Часові пояси завжди розрізняються на ціле число годинника щодо універсального синхронізованого часу (UTC).
58. Перехід на літній час всюди починається/закінчується в один і той же день.
59. Перехід на літній час завжди являє собою зсув на 1 годину вперед.
60. Зчитування годин клієнта і порівняння з UTC є хорошим способом визначити часовий пояс клієнта.
61. Програмно-реалізований стек буде / не буде намагатися автоматично налаштуватися на часовий пояс / перехід на літній час.
62. Моя програма використовується тільки всередині підприємства / локально, тому мені не треба турбуватися про годинних поясах.
63. Мій програмно-реалізований стек буде обробляти це без необхідності будь-якого мого втручання.
64. Я можу легко зберегти список часових поясів сам.
65. Всі вимірювання часу на даних годинах будуть відбуватися в одній і тій же системі відліку.
66. Той факт, що заснована на дату функція зараз працює, означає, що вона буде працювати за будь-якої дати.
67. Рік містить 365 або 366 днів.
68. За кожною календарною датою розташовується послідовно подальша без пропуску.
69. Наведена дата і/або показання годин однозначно ідентифікують унікальний момент часу.
70. Високосні роки мають місце кожні 4 роки.
71. Знаючи область/район, можна визначити їх часовий пояс.
72. Знаючи населений пункт, можна визначити його часовий пояс.
73. Час іде з однаковою швидкістю на вершині гори і в самій нижній частині долини.
74. Одна година дорівнює наступного у всіх системах відліку часу.
75. Можна розрахувати, коли будуть додані високосні секунди.
76. Точність типу даних, що повертаються функцією getCurrentTime(), є тією ж, що і точність цієї функції.
77. Два послідовних виклику функції getCurrentTime() повернуть розрізняються результати.
78. Другий з двох послідовних викликів функції getCurrentTime() поверне більшого значення.
79. Дане програмне забезпечення ніколи буде працювати на космічному кораблі, облетающем чорну діру.

Серйозно? Чорну діру?

Ну, якщо Брюс Стерлінг говорить, що моє ПО повинне бути стійке проти тимчасових спотворень поблизу чорної діри — зловлю його на слові.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.