You are sure that some - if not all - of these statements are true always and everywhere:
- There are always 24 hours in a day.
- A week always starts and ends in the same month.
- A week (or month) always starts and ends in the same year.
- Time has no beginning or end.
- There can be 28, 29, 30 or 31 days in a month.
- There is a leap year every 4 years.
- In every month, the same number of days is always everywhere.
- The server and client will always have the same time.
- You can easily calculate the number of hours and minutes starting from some point in time.
- Each minute has 60 seconds.
Although practice shows that it is a delusion to rely on the truth of these statements when developing software. Well, okay, not all of these points are misconceptions . Some of the statements would be true if not for the annoying bugs and edge cases, which have accumulated a myriad of over the history of software.
Each minute has 60 seconds, and there are always 24 hours in a day
For example, in older versions of KVM in CentOS there was a curious bug - a minute could last as long as you like. The fact is that KVM did not know that it was not running on physical hardware, and if the hosting OS temporarily suspended the virtual machine, then the virtualized clock continued to run from the moment it was suspended . For example, if a car was paused at 13:00 and activated at 15:00, the system clock in it continued to show 13:00. As a result, after each pause, there was a discrepancy with real time. There was even a cron task that could be set up to synchronize the virtualized clock with the hardware clock. But when creating a new virtual machine, it was easy to forget about it, and it was fun. The bug was later fixed.
Aside from the bugs, there is also a leap second (extra) second: it is added to UTC (Coordinated Universal Time) at the end of the day on June 30 or December 31 to compensate for the gradual slowing down of the Earth's rotation and the accumulation of the difference between the SI and astronomical days. - sunny - for days.
As for the length of the day, the main enemy of the programmer is the transition to daylight saving time, which is somewhere there, somewhere it is not, and earlier it could be canceled or introduced. This is a separate big problem with historical data - daylight savings time.
And if we add to this the change of time zones ...
About weeks, months and years
But stories about different lengths of months and years are associated with different calendar calculations for different peoples of the world. For example, the Jewish calendar operates with lunar months: that is, the beginning and end of the month are tied to the phases of the moon. Do you think you can easily take this into account by adding an adjustment for Israel with the loading of the lunar phases? Will not work. In a Jewish leap year, an extra month is added . Moreover - watch your hands - both simple and leap years in the Hebrew calendar can have three different lengths . In total, a year can have six different lengths.from 354 to 383 days. Do you think this is the end of the differences from our calendar? Where is there: in the Jewish calendar, days have different durations and are counted from sunset to sunset (formally, when three stars become visible in the sky).
Do you think that it is only for the Jews that everything is not like in the Gregorian calendar (to the question of the Great October Socialist Revolution, which was celebrated in the USSR on November 7)? In Arab countries:
- The week does not start on Monday, but on Sunday.
- The weekend is considered Friday and Saturday, and in some countries - Thursday and Friday. Over the past 10 years, some states have moved the weekend to Friday and Saturday to facilitate international trade. And yet not all Arab countries have a weekend of two days.
- Religious holidays depend on observations of the lunar cycle, so their timing cannot be accurately predicted.
As for the fact that weeks and months may end next year, this is again typical for countries with lunar and solar-lunar calendars - in them the new year does not begin on January 1. Offhand, you can immediately recall the Chinese, whose new year begins in the period from January 21 to February 21 according to the Gregorian calendar. And in the Ethiopian calendar, the new year is generally August 29 or 30, and even the number of years they have is 8 less than in the system "from the birth of Christ."
The server and client will always have the same time
And here is an interesting fact, due to which the time on different computers may not only not coincide, but even the size of the discrepancy may vary. When Linux boots up, it takes the current hardware time, and then counts it down further, adding data from the internal processor clock (TSC). These clocks can be quite inaccurate. For example, due to clock scaling, which dynamically changes the TSC frequency. And if you change the clock frequency on the host, then all guest accounts will not even notice it. If you scale the TSC frequency by 50%, the time will start to run twice as slow. In addition, on some servers, the BIOS can scale the processor frequency without notifying the OS, which also adds an error. On newer processors, the TSC frequencies are now fixed. By the way, Windows does not use TSC, so this OS has other problems with timing:)
You can easily calculate the number of hours and minutes starting from some point in time
Unless there is something like Python in the programming language
tzinfo()
, you cannot get a specific date and time by simply adding hours and minutes to some date in the past. It is necessary to take into account the time zones (and their possible change, as has happened more than once in history), then take into account all the changes in the transition to daylight saving time ... In Windows, this is generally impossible, because Microsoft provides only the beginning and end of the current year. Surprisingly, after so many DST handling patches, the company still hasn't implemented a Windows equivalent
tzinfo()
. Probably not.
Time has no beginning and no end
"Your program will never need to handle dates before 1970." On Unix systems (including Linux and iOS), time is counted in seconds since 00:00:00 on January 1, 1970 UTC (Coordinated Universal Time). Anything earlier in Unix will already be negative time. Moreover, the time is represented in a 32-bit integer expression, and the earliest date possible in Unix systems is December 13, 1901. And the "top" Unix-time is limited to January 19, 2038, when the number of seconds from the beginning of the countdown reaches 2 31 , and this number can be considered negative by the system.
All this is just a small part of the huge number of nuances and bugs that developers of any time-consuming product have to cope with. Surely you also have a story to tell from your experience, write in the comments.