What every programmer should know about time

Some notes about time

• UTC : time on the zero meridian is called Universal Coordinated Time, Universal Coordinated Time. The disagreement of the acronym was caused by the necessity of its universality for all languages.
• GMT : previously, instead of UTC, the Greenwich Mean Time (GMT) was used, since the zero meridian was chosen so as to pass through the Greenwich Royal Observatory.
• Other time zones can be recorded as an offset from UTC. For example, the Australian Eastern Standard Time (EST) is recorded as UTC + 1000, that is, the time 10:00 UTC is 20:00 EST on the same day.
• Summer time does not affect UTC. This is just a political decision to change the time zone (offset from UTC). For example, GMT is still used: this is the British national time in winter. In the summer it becomes BST.
• Leap seconds : by international agreement, UTC lasts no more than 0.9 seconds from physical reality (UT1, measured in solar time) by introducing a “leap second” at the end of the last minute of the year according to UTC or the last minute of June.
• Leap seconds are not required to be announced (by astronomers) more than 6 months prior to their introduction. This is a problem if you need any planning with second accuracy for more than 6 months.
• Unix time : measured by the number of seconds elapsed since the “era” (early 1970 UTC). Time zones or summertime do not affect Unix time.
• According to the POSIX.1 standard, for Unix time it is supposed to handle leap seconds by repeating the previous second, for example:

    59.00
       59.25
       59.50
       59.75
       59.00 ← repeat
       59.25
       59.50
       59.75
       00.00 ← increment
       00.25 

  This is a trade-off: you cannot express a leap second in your system clock in any way and your time is guaranteed to go in the opposite direction. On the other hand, every day is exactly 86,400 seconds, and you do not need a table of all past and future leap seconds in order to translate Unix-time into a convenient for a person form of hours-minutes-seconds.
• It is assumed that ntpd will repeat after it receives “leap bits” from the upstream time servers, but I also saw how it does nothing: the system goes one second into the future, then slowly slips back to the right time.

What every programmer should know about time

• Time zones refer to presentation level.
  Most of your code should not be involved in time zones or local time, it should pass Unix-time as it is.
• When measuring time, measure Unix time. This is UTC. Its easy to get (system functions). It does not have time zones or daylight saving time (and leap seconds).
• When store time, store Unix time. This is one number.
• If you want to save time suitable for reading by a person (for example, in logs), try to save it with Unix-time, and not instead .
• When displaying time, always include a time zone offset in it. The time format without offset is useless.
• System clock is not accurate.
• You are online? The system clock of each other machine is not accurate in different ways.
• System clocks can, and will, jump forward and back in time due to things that are beyond your control. Your program should be designed to survive this.
• The ratio of the number of seconds of the system clock to the number of real seconds is not accurate and may vary. It mainly depends on the temperature.
• Do not blindly use gettimeofday() . If you need a monotone (constantly increasing) clock, look at clock_gettime() . [Java option: instead of System.currentTimeMillis() use System.nanoTime() ]
• ntpd can change the system time in two ways:
  • Step: the clock jumps forward or back to the correct time immediately
  • Twist: change the frequency of the system clock so that it slowly moves in the direction of the correct time.
  Twisting is more preferable because it is less destructive, but useful only for correcting a small difference.

Special cases

• Time passes at a rate of one second per second for all observers. The frequency of the remote clock in relation to the observer depends on the speed and gravity. The clock inside the GPS satellites is adjusted to overcome the effects of relativity.
• MySQL stores DATETIME columns as YYYYMMDD HHMMSS values ​​packed in numbers. If you are concerned about storing time stamps, store them as an integer and use the UNIX_TIMESTAMP () and FROM_UNIXTIME () functions to convert.