Programmers misconceptions regarding time
Over the past couple of years I have spent a lot of time debugging other people's tests. It was an interesting job, sometimes frustrating, but always instructive. Someone might think that there are no bugs in the tests, but of course there are bugs everywhere , and tests are no exception.
I was constantly amazed at how many errors in the code and tests and applications come from misunderstandings and misconceptions about time . By this, I mean both the computer method of time processing and the fundamental errors stemming from the imperfect calendar structure - summer time is only the tip of the iceberg.
In fact, I have seen so many misconceptions that leave a mark in other people's (and my own) programs, that I thought it would be useful to make a list of the most frequent problems.
All these assumptions are wrong.
1. There are always 24 hours in a day.
2. In the month is always 30 or 31 days.
3. In years of 365 days.
4. February is always 28 days.
5. Any 24-hour period begins and ends on the same day (week, month).
6. A week always begins and ends in the same month.
7. A week (month) always begins and ends in the same year .
8. The machine on which the program is running will always be in GMT time zone.
9. Okay, that's not true. But at least the time zone will not change.
10. Well, certainly the time zone will not change when the program is in commercial use .
11. The system clock is always set to the exact local time.
12. The system clock will always be set to a time that is not much different from the exact local time.
13. If the system clock goes wrong, then at least they will always differ by the same number of seconds.
14. The clock on the server and the client always show the same time.
15. The clock on the server and the client always show approximately the same time.
16. Ok, but server time and client time will never differ by decades .
17. If the clock on the server and client are out of sync, they are at least always out of sync for a constant number of seconds.
18. The clock on the server and the client go in the same time zone.
19. The system clock never shows the time that belongs to the distant past or distant future.
20. Time has no beginning and end .
21. One minute on a system clock has exactly the same duration as one minute on any other clock .
22. Ok, but the duration of one minute on the system clock will be close to the duration of one minute on most other hours.
23. Good, but the duration of one minute on the system clock will never be more than an hour.
24. Yes, you're kidding.
25. The minimum unit of time is one second.
26. Well, one millisecond.
27. It will never be necessary to rearrange the system clock to a value other than the exact local time.
28. Okay, for testing it may be necessary to rearrange the system clock to another value, but in commercial operation it will never be needed.
29. Time stamps (time stamps) will always be in a clear format like 1339972628 or 133997262837.
30. Time stamps will always be in the same format.
31. Time stamps will always have the same degree of accuracy.
32. The time stamp of sufficient accuracy can be considered unique.
33. The time stamp indicates the time when the event actually occurred.
34. Human-readable dates can be transferred in a universal, understandable format like 05/07/11.
')
That joke about a minute that lasts longer than an hour was a joke?
Not.
There was a charming bug in older versions of KVM on CentOS. The KVM virtual machine did not have a clue what was running on the physical hardware. Thus, if the parent OS sent the virtual machine to sleep mode, then after waking up on the system clock of the virtual machine it was the same time as at the time of falling asleep. For example, if the VM fell asleep at 13:00 and returned to the active state after two hours (at 15:00), then the VM system clock will still show the local time at 13:00.
It was possible to start a demon that would synchronize time all the time, but for new virtual machines it was often forgotten, which led to very funny situations. Bug fixed in the next versions.
PS This publication was inspired by the cult post of Patrick Mackenzie about user names , which I reread over and over again over several years, and from where I shamelessly borrowed both structure and style. If you have not read this masterpiece, go and read right now. I promise you will like it.
I was constantly amazed at how many errors in the code and tests and applications come from misunderstandings and misconceptions about time . By this, I mean both the computer method of time processing and the fundamental errors stemming from the imperfect calendar structure - summer time is only the tip of the iceberg.
In fact, I have seen so many misconceptions that leave a mark in other people's (and my own) programs, that I thought it would be useful to make a list of the most frequent problems.
All these assumptions are wrong.
1. There are always 24 hours in a day.
2. In the month is always 30 or 31 days.
3. In years of 365 days.
4. February is always 28 days.
5. Any 24-hour period begins and ends on the same day (week, month).
6. A week always begins and ends in the same month.
7. A week (month) always begins and ends in the same year .
8. The machine on which the program is running will always be in GMT time zone.
9. Okay, that's not true. But at least the time zone will not change.
10. Well, certainly the time zone will not change when the program is in commercial use .
11. The system clock is always set to the exact local time.
12. The system clock will always be set to a time that is not much different from the exact local time.
13. If the system clock goes wrong, then at least they will always differ by the same number of seconds.
14. The clock on the server and the client always show the same time.
15. The clock on the server and the client always show approximately the same time.
16. Ok, but server time and client time will never differ by decades .
17. If the clock on the server and client are out of sync, they are at least always out of sync for a constant number of seconds.
18. The clock on the server and the client go in the same time zone.
19. The system clock never shows the time that belongs to the distant past or distant future.
20. Time has no beginning and end .
21. One minute on a system clock has exactly the same duration as one minute on any other clock .
22. Ok, but the duration of one minute on the system clock will be close to the duration of one minute on most other hours.
23. Good, but the duration of one minute on the system clock will never be more than an hour.
24. Yes, you're kidding.
25. The minimum unit of time is one second.
26. Well, one millisecond.
27. It will never be necessary to rearrange the system clock to a value other than the exact local time.
28. Okay, for testing it may be necessary to rearrange the system clock to another value, but in commercial operation it will never be needed.
29. Time stamps (time stamps) will always be in a clear format like 1339972628 or 133997262837.
30. Time stamps will always be in the same format.
31. Time stamps will always have the same degree of accuracy.
32. The time stamp of sufficient accuracy can be considered unique.
33. The time stamp indicates the time when the event actually occurred.
34. Human-readable dates can be transferred in a universal, understandable format like 05/07/11.
')
That joke about a minute that lasts longer than an hour was a joke?
Not.
There was a charming bug in older versions of KVM on CentOS. The KVM virtual machine did not have a clue what was running on the physical hardware. Thus, if the parent OS sent the virtual machine to sleep mode, then after waking up on the system clock of the virtual machine it was the same time as at the time of falling asleep. For example, if the VM fell asleep at 13:00 and returned to the active state after two hours (at 15:00), then the VM system clock will still show the local time at 13:00.
It was possible to start a demon that would synchronize time all the time, but for new virtual machines it was often forgotten, which led to very funny situations. Bug fixed in the next versions.
PS This publication was inspired by the cult post of Patrick Mackenzie about user names , which I reread over and over again over several years, and from where I shamelessly borrowed both structure and style. If you have not read this masterpiece, go and read right now. I promise you will like it.
Source: https://habr.com/ru/post/146109/
All Articles