Misconceptions of most programmers regarding "time"
Many days ago, I decided to record some observations that have been formed so far in recent years I have been testing. Considering the areas that get the most out of testing, I realized that I had a lot of specific thoughts about how we, programmers, tend to carelessly use the concept of “time” in programming.
Then I wrote the post “Misconceptions of programmers regarding“ time ” , in which I pointed out 34 erroneous ideas and misconceptions relating to both calendar and system time. I encountered most of them myself, doing debugging of programs (both working and test ones).
Many of these erroneous ideas were my own. In particular, “time stamps are always in seconds since the beginning of an epoch” and “the duration of one minute on the system clock is always close to the duration of one minute of physical time”. All my life I will painfully remember my delusion in these two cases! But, of course, undoubtedly - I am not the only one who ran into such problems (or inadvertently created them). Many people responded and shared similar experiences.
')
First of all, it was noted the absence of a false assumption that “time always moves forward,” as noted by Technomancy and many others. I enjoyed reading all the suggestions in the list. When I finished reading, I realized that, by and large, they are just another blog post. Therefore, I have collected all your suggestions in one post and present it below.
All the following assumptions “in time” were proposed by the participants in the discussion of the initial post . Each member is listed at the end of the article.
1. The difference between the two time zones will remain constant.
2. Well, putting aside the historical curiosities , the difference between the two time zones will not change in the future.
3. The change in the difference between time zones will occur with the issuance of a set of preliminary alerts.
4. The transition to summer time occurs every year at the same time.
5. Daylight saving time occurs in each time zone at the same time.
6. When switching to summer time, there is always a one hour shift.
7. The number of days in a month is 28, 29, 30 or 31.
8. The day of the month always changes sequentially from N to N + 1 or to 1 without any break.
9. At a time, only one calendar system is used.
10. A leap year takes place in each year, which is divided by 4.
11. The non-leap year never takes place on February 29th.
12. It is easy to count the number of hours and minutes elapsed from a certain point in time.
13. The same month contains the same number of days everywhere!
14. Time in Unix is ​​measured only in seconds.
15. Time in Unix is ​​the number of seconds since January 1, 1970.
16. Saturday is always preceded by Friday.
17. Neighboring time zones differ by no more than one hour (in other words: we should not check what happens to avionics when flying over the date line).
18. Two different time zones differ by an integer number of half-hours.
19. Ok, for an integer quarter hour.
20. Ok, for a second, but it will be a significant difference if we do not take into account the transition to daylight saving time.
21. If you create two date objects right next to each other, they will represent the same time (Heisenberg’s fantastic generator).
22. You can wait until the clock shows exactly HH: MM: SS with sampling once per second.
23. If the process is “n” seconds and then terminates, then approximately “n” seconds have passed on the system clock by the end time.
24. Week starts on Monday.
25. The day begins in the morning.
26. Holidays take an integer full day.
27. Weekends consist of Saturdays and Sundays.
28. You can set a general procedure for the formation of timestamps, which will be useful outside of your system.
29. Local time offset (relative to universal time synchronized (UTC)) will not change during the working day.
30. Thread.sleep (1000) suspends execution for 1000 milliseconds.
31. Thread.sleep (1000) suspends execution for a time> = 1000 milliseconds.
32. Every minute contains 60 seconds.
33. Time stamps are always monotonous .
34. Greenwich Mean Time (GMT) and Universal Synchronized Time (UTC) represent the same time zone.
35. The UK uses Greenwich Mean Time (GMT).
36. Time always moves forward.
37. The difference between the current point in time and a point in time that is one week apart is always 7 * 86400 seconds.
38. The difference between the two time stamps is a precise measure of the time elapsed between them.
39. 24:12:34 is the wrong time.
40. Each integer could theoretically mean a year.
41. When the date and time are displayed, the time shown has the same second part as the time stored in the memory.
42. Or the same year.
43. But at least the difference between the displayed and stored year does not exceed 2.
44. If the data is in the correct format YYYY-MM-DD, then the year contains four digits.
45. If there is a merging of two dates by borrowing the month from the first, and the day and / or year from the second, then the date is correct.
46. ​​But it will work only if both years are leap years.
47. If you take the published algorithm described by the W3C specification to add a certain duration to the dates, it will work in all cases.
48. The standard library supports negative years and years exceeding 10,000.
49. Time zones are always different for a whole hour.
50. When converting a timestamp that has an accuracy in milliseconds, at a time that has an accuracy in seconds, you can safely ignore the components in milliseconds.
51. You can ignore the component in milliseconds, if it is less than 0.5.
52. The year presented in the form of two figures should be in the range of 1900-2099.
53. When parsing time, dates can be read numbers sequentially (character by character) without having to go back.
54. When printing time, dates, you can write numbers sequentially (character by character) without having to go back.
55. You will never have to parse something like this — 12Z or P12Y34M56DT78H90M12.345S.
56. There are only 24 time zones.
57. Time zones always differ by an integer number of hours relative to universal synchronized time (UTC).
58. Daylight saving time starts everywhere / ends on the same day.
59. Daylight saving time is always a 1 hour advance.
60. Reading the customer’s hours and comparing with UTC is a good way to determine the customer’s time zone.
61. Software-implemented stack will / will not attempt to automatically tune to time zone / daylight saving time.
62. My program is used only inside the enterprise / locally, so I do not need to worry about time zones.
63. My software stack will handle this without the need for any intervention.
64. I can easily save the list of time zones by myself.
65. All measurements of time on these clocks will occur in the same reference system .
66. The fact that the date-based function is now working means that it will work on any date.
67. Year contains 365 or 366 days.
68. Behind each calendar date there is a further one without skipping.
69. The given date and / or the clock readings uniquely identify a unique point in time.
70. Leap years occur every 4 years.
71. Knowing the area / district, you can determine their time zone.
72. Knowing the locality, you can determine its time zone.
73. Time passes with the same speed at the top of the mountain and at the very bottom of the valley.
74. One hour is equal to the next in all time systems.
75. You can calculate when leap seconds are added.
76. The accuracy of the data type returned by the getCurrentTime () function is the same as the accuracy of this function.
77. Two consecutive calls to the getCurrentTime () function will return different results.
78. The second of two consecutive calls to the getCurrentTime () function will return a larger value.
79. This software will never work on a spacecraft flying around a black hole.
Well, if Bruce Sterling says that my software should be stable against temporal distortions near the black hole - I'll catch it on the word.
Then I wrote the post “Misconceptions of programmers regarding“ time ” , in which I pointed out 34 erroneous ideas and misconceptions relating to both calendar and system time. I encountered most of them myself, doing debugging of programs (both working and test ones).
Many of these erroneous ideas were my own. In particular, “time stamps are always in seconds since the beginning of an epoch” and “the duration of one minute on the system clock is always close to the duration of one minute of physical time”. All my life I will painfully remember my delusion in these two cases! But, of course, undoubtedly - I am not the only one who ran into such problems (or inadvertently created them). Many people responded and shared similar experiences.
UPDATED: I would like to sincerely thank everyone who participated in the discussion of this post. I read every comment and found out about different funny things, such as, for example, annual zero and international atomic time.I would like to express my deep gratitude to everyone who contributed to the discussion on BoingBoing , Hacker News , Reddit , MetaFilter and Twitter, and shared his unusual experience with “time” in programming. In this one thousand or so answers, there were many offers to continue the list of “errors”.
')
First of all, it was noted the absence of a false assumption that “time always moves forward,” as noted by Technomancy and many others. I enjoyed reading all the suggestions in the list. When I finished reading, I realized that, by and large, they are just another blog post. Therefore, I have collected all your suggestions in one post and present it below.
All these assumptions are wrong.
All the following assumptions “in time” were proposed by the participants in the discussion of the initial post . Each member is listed at the end of the article.
1. The difference between the two time zones will remain constant.
2. Well, putting aside the historical curiosities , the difference between the two time zones will not change in the future.
3. The change in the difference between time zones will occur with the issuance of a set of preliminary alerts.
4. The transition to summer time occurs every year at the same time.
5. Daylight saving time occurs in each time zone at the same time.
6. When switching to summer time, there is always a one hour shift.
7. The number of days in a month is 28, 29, 30 or 31.
8. The day of the month always changes sequentially from N to N + 1 or to 1 without any break.
9. At a time, only one calendar system is used.
10. A leap year takes place in each year, which is divided by 4.
11. The non-leap year never takes place on February 29th.
12. It is easy to count the number of hours and minutes elapsed from a certain point in time.
13. The same month contains the same number of days everywhere!
14. Time in Unix is ​​measured only in seconds.
15. Time in Unix is ​​the number of seconds since January 1, 1970.
16. Saturday is always preceded by Friday.
17. Neighboring time zones differ by no more than one hour (in other words: we should not check what happens to avionics when flying over the date line).
18. Two different time zones differ by an integer number of half-hours.
19. Ok, for an integer quarter hour.
20. Ok, for a second, but it will be a significant difference if we do not take into account the transition to daylight saving time.
21. If you create two date objects right next to each other, they will represent the same time (Heisenberg’s fantastic generator).
22. You can wait until the clock shows exactly HH: MM: SS with sampling once per second.
23. If the process is “n” seconds and then terminates, then approximately “n” seconds have passed on the system clock by the end time.
24. Week starts on Monday.
25. The day begins in the morning.
26. Holidays take an integer full day.
27. Weekends consist of Saturdays and Sundays.
28. You can set a general procedure for the formation of timestamps, which will be useful outside of your system.
29. Local time offset (relative to universal time synchronized (UTC)) will not change during the working day.
30. Thread.sleep (1000) suspends execution for 1000 milliseconds.
31. Thread.sleep (1000) suspends execution for a time> = 1000 milliseconds.
32. Every minute contains 60 seconds.
33. Time stamps are always monotonous .
34. Greenwich Mean Time (GMT) and Universal Synchronized Time (UTC) represent the same time zone.
35. The UK uses Greenwich Mean Time (GMT).
36. Time always moves forward.
37. The difference between the current point in time and a point in time that is one week apart is always 7 * 86400 seconds.
38. The difference between the two time stamps is a precise measure of the time elapsed between them.
39. 24:12:34 is the wrong time.
40. Each integer could theoretically mean a year.
41. When the date and time are displayed, the time shown has the same second part as the time stored in the memory.
42. Or the same year.
43. But at least the difference between the displayed and stored year does not exceed 2.
44. If the data is in the correct format YYYY-MM-DD, then the year contains four digits.
45. If there is a merging of two dates by borrowing the month from the first, and the day and / or year from the second, then the date is correct.
46. ​​But it will work only if both years are leap years.
47. If you take the published algorithm described by the W3C specification to add a certain duration to the dates, it will work in all cases.
48. The standard library supports negative years and years exceeding 10,000.
49. Time zones are always different for a whole hour.
50. When converting a timestamp that has an accuracy in milliseconds, at a time that has an accuracy in seconds, you can safely ignore the components in milliseconds.
51. You can ignore the component in milliseconds, if it is less than 0.5.
52. The year presented in the form of two figures should be in the range of 1900-2099.
53. When parsing time, dates can be read numbers sequentially (character by character) without having to go back.
54. When printing time, dates, you can write numbers sequentially (character by character) without having to go back.
55. You will never have to parse something like this — 12Z or P12Y34M56DT78H90M12.345S.
56. There are only 24 time zones.
57. Time zones always differ by an integer number of hours relative to universal synchronized time (UTC).
58. Daylight saving time starts everywhere / ends on the same day.
59. Daylight saving time is always a 1 hour advance.
60. Reading the customer’s hours and comparing with UTC is a good way to determine the customer’s time zone.
61. Software-implemented stack will / will not attempt to automatically tune to time zone / daylight saving time.
62. My program is used only inside the enterprise / locally, so I do not need to worry about time zones.
63. My software stack will handle this without the need for any intervention.
64. I can easily save the list of time zones by myself.
65. All measurements of time on these clocks will occur in the same reference system .
66. The fact that the date-based function is now working means that it will work on any date.
67. Year contains 365 or 366 days.
68. Behind each calendar date there is a further one without skipping.
69. The given date and / or the clock readings uniquely identify a unique point in time.
70. Leap years occur every 4 years.
71. Knowing the area / district, you can determine their time zone.
72. Knowing the locality, you can determine its time zone.
73. Time passes with the same speed at the top of the mountain and at the very bottom of the valley.
74. One hour is equal to the next in all time systems.
75. You can calculate when leap seconds are added.
76. The accuracy of the data type returned by the getCurrentTime () function is the same as the accuracy of this function.
77. Two consecutive calls to the getCurrentTime () function will return different results.
78. The second of two consecutive calls to the getCurrentTime () function will return a larger value.
79. This software will never work on a spacecraft flying around a black hole.
Seriously? Black hole?
Well, if Bruce Sterling says that my software should be stable against temporal distortions near the black hole - I'll catch it on the word.
Source: https://habr.com/ru/post/313274/
All Articles