[{"@context":"http:\/\/schema.org\/","@type":"BlogPosting","@id":"https:\/\/wiki.edu.vn\/all2en\/wiki32\/heurre-unix-wikipedia\/#BlogPosting","mainEntityOfPage":"https:\/\/wiki.edu.vn\/all2en\/wiki32\/heurre-unix-wikipedia\/","headline":"Heurre unix \u2014 wikipedia","name":"Heurre unix \u2014 wikipedia","description":"before-content-x4 L’ UNIX hour or POSIX hour (also called Unix Timestamp ) is a measure of time based on the","datePublished":"2020-09-26","dateModified":"2020-09-26","author":{"@type":"Person","@id":"https:\/\/wiki.edu.vn\/all2en\/wiki32\/author\/lordneo\/#Person","name":"lordneo","url":"https:\/\/wiki.edu.vn\/all2en\/wiki32\/author\/lordneo\/","image":{"@type":"ImageObject","@id":"https:\/\/secure.gravatar.com\/avatar\/44a4cee54c4c053e967fe3e7d054edd4?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/44a4cee54c4c053e967fe3e7d054edd4?s=96&d=mm&r=g","height":96,"width":96}},"publisher":{"@type":"Organization","name":"Enzyklop\u00e4die","logo":{"@type":"ImageObject","@id":"https:\/\/wiki.edu.vn\/wiki4\/wp-content\/uploads\/2023\/08\/download.jpg","url":"https:\/\/wiki.edu.vn\/wiki4\/wp-content\/uploads\/2023\/08\/download.jpg","width":600,"height":60}},"image":{"@type":"ImageObject","@id":"https:\/\/upload.wikimedia.org\/wikipedia\/commons\/thumb\/f\/fb\/Leapsecond.ut1-utc.svg\/220px-Leapsecond.ut1-utc.svg.png","url":"https:\/\/upload.wikimedia.org\/wikipedia\/commons\/thumb\/f\/fb\/Leapsecond.ut1-utc.svg\/220px-Leapsecond.ut1-utc.svg.png","height":"176","width":"220"},"url":"https:\/\/wiki.edu.vn\/all2en\/wiki32\/heurre-unix-wikipedia\/","wordCount":7333,"articleBody":"     (adsbygoogle = window.adsbygoogle || []).push({});before-content-x4L’ UNIX hour or POSIX hour (also called Unix Timestamp ) is a measure of time based on the number of seconds sold from the first is January 1970 00:00:00 UTC, excluding second intercalarse. It is used mainly in systems that respect the POSIX standard [ first ] , including UNIX type systems, hence its name. It is the POSIX representation of time.        (adsbygoogle = window.adsbygoogle || []).push({});after-content-x4   This graph shows the DUT1 difference between UT1 and UTC. The vertical segments correspond to the insertion of inter -lap seconds. Table of Contents       (adsbygoogle = window.adsbygoogle || []).push({});after-content-x4Associate an event in time with a real number [ modifier | Modifier and code ] Main measurement systems used [ modifier | Modifier and code ] Choice of an origin of time [ modifier | Modifier and code ] Evolution of time [ modifier | Modifier and code ] Time elapsed between two events [ modifier | Modifier and code ] UTC Time Conversion in Hour Posix [ modifier | Modifier and code ] One hour POSIX conversion in UTC hour [ modifier | Modifier and code ] Limited number of years that a particular UNIX system can represent [ modifier | Modifier and code ] Use of a resolution below the second [ modifier | Modifier and code ] Use of TAI [ modifier | Modifier and code ] Gigaseconde Unix [ modifier | Modifier and code ] Related articles [ modifier | Modifier and code ] external links [ modifier | Modifier and code ] Bibliography [ modifier | Modifier and code ] Associate an event in time with a real number [ modifier | Modifier and code ] To associate an event with a real number, it is enough to use natural and universal references: for example, the periodicities of rotation of the earth on itself, and around the sun. These periodicities are sufficient to establish calendars, that is to say relations between events and dates, even if some efforts are necessary to properly define the references used [ 2 ] (Each country has its own, all adopted at different moments); The dates of these calendars are only numbers expressed in a somewhat complicated counting system which has for units during the day, week, month, season, year, etc., and POSIX time is than a reference among others expressed in the form of a simple number. Main measurement systems used [ modifier | Modifier and code ] Here are the main time measurement systems that have been imagined and used to the present day [ 3 ] : Abbreviation Signification Definition GMT Average Greenwich Time [ 4 ] Still in use in certain countries for legal aspects [ 5 ] . However, the definition of this measurement system is ambiguous [ 4 ] . This is the reason why, apart from this administrative use, it is preferable to use UTC.        (adsbygoogle = window.adsbygoogle || []).push({});after-content-x4OUT Universal time This system defines the day as the average time of rotation of the earth around its axis. This definition poses some difficulties because the speed of this rotation is not constant, it decreases slowly under the effect of tides and, moreover, has unpredictable irregularities: the duration of UT days is very slightly higher, on average, to 86,400 seconds (number of seconds in 24 hours). The gap is of the order of the second over one to three years. There are several versions of UT: UT0, UT1, UT1R, UT2. We will refer to the article “Universal Time” for more details. EARS International atomic time This system is based on an international definition of the second. Its stallion is made up of several atomic clocks distributed in the world. The measurement of time in this system is strictly regular unlike the previous one for which its stallion does not have the same regularity. Consequently, Tai and UT gradually move away from each other due to the slowdown of the second. A difference in two TAIs makes it possible to calculate an exactly elapsed time. UTC Coordinated universal time This system is adopted as the basis of international civilian time by a large number of countries. The word “coordinated” indicates that: The difference between UTC and Tai is a whole number of seconds, The difference between UTC and UT1 is never larger than 0.9 seconds. In other words, UTC is identical to the TAI (it has its stability and accuracy) to a whole number of seconds [ 6 ] , and the second interlayers allow him to stick to UT at 0.9 s close ; This is what the figure above shows [ 7 ] . Respect for this maximum difference between UT and UTC is guaranteed by the “International Earth Rotation and Reference Systems Service” (ISRS), founded in particular to the Paris Observatory, which decides [ 8 ] to add (or delete) of the second intercalale each time AUT and UT deviate too much from each other. A difference of two hours UTC makes it possible to calculate an exactly elapsed delay as long as the two events are not straddling an inter-lap second (see below the probability and the amplitude of the error). To calculate an exact delay in all circumstances, it is necessary to take into account the second intercalaRes [ 9 ] . Choice of an origin of time [ modifier | Modifier and code ] To measure time, you have to choose an origin: The origin of the POSIX hour was chosen as being the first is January 1970 00:00:00 UTC [ ten ] , this date corresponds to the time 0 of posix, it is called the epoch POSIX (and also Epoch Unix). Evolution of time [ modifier | Modifier and code ] It is necessary to indicate how this number evolves according to the passing time: For every second elapsed, the Hour Posix increases exactly one unit and this invariable throughout the year, except when ISS decides [ 8 ] to add (or delete) an interlayer second; the table below illustrates the case of the addition of the second interlayer which took place the December 31, 2008 at midnight [ 11 ] . Table 1: The POSIX hour on the midnight passage when a second interlayer was added the December 31, 2008 at midnight # EARS UTC Tai – UTC POSIX hour  first 2009-01-01T00: 00: 30 2008-12-31T23: 59: 57 33 1 230 767 997  2 2009-01-01T00: 00: 31 2008-12-31T23: 59: 58 33 1 230 767 998  3 2009-01-01T00: 00: 32 2008-12-31T23: 59: 59 33 1 230 767 999  4 2009-01-01T00: 00: 33  2008-12-31T23: 59: 60  33 1 230 768 000  Addition of an inter -lap second [ twelfth ] 5 2009-01-01T00: 00: 34  2009-01-01T00: 00: 00  34  1 230 768 000   6 2009-01-01T00: 00: 35 2009-01-01T00: 00: 01 34  1 230 768 001  7 2009-01-01T00: 00: 36 2009-01-01T00: 00: 02 34  1 230 768 002  The POSIX hour is not a linear representation of time, there are anomalies [ twelfth ] , like line 5 of the table above. There is no bijective correspondence between UTC time and POSIX time; The latter does not allow to represent the second intercalaire present in UTC, such as line 4 of the table above: 2008-12-31T23: 59: 60 \u00a0UTC. Time elapsed between two events [ modifier | Modifier and code ] These different references should not be mixed (for example, the zero year of a calendar does not start at the same time as that of another) and also because all these calendars need to adapt to non -multiple periodicities Each other, for example, in the long time, or the irregularities of these periodicities. These adaptations a little complicate the calculations, depending on the precision that we are looking for; For example, It has passed a year Perhaps sufficient information or it will be necessary to take into account the bissextile character of the year to answer the same question expressed in number of days. This means that it is necessary to keep a memory of the past, the memory of each passing second. In most cases, a simple difference in the hours POSIX is enough, unless the two events are straddling one or more seconds interlayer. To calculate an exact delay in all circumstances, it is necessary to take into account the second intercalaire. However, the occurrence of the second intercalale is low [ 13 ] , the probability of committing such an error is therefore low; And if despite all the case occurs, then the amplitude of the error is perhaps low [ 14 ] , and in this case there is no need to be concerned with these second interlayers; The table below shows different examples. The method to complete a line in this table is as follows: If the period calculated between the two events of interest is around the seconds, then the probability that a second interlayer is in this interval is M on the total number n of seconds for a year (i.e. to be said to assume that a second interlayer is added each year), One year count n = 365 x 24 x 3,600 = 31,536,000 seconds, The probability of making a 1\/m error is therefore m\/n = mx3.2 \u00d7 10 -8 . The application of this method for deadlines M = 10, 100, 1000 gives the following table: Table 2: Error made and probability of making the error Deadline to be measured (m) Probability of error Error amplitude ten s 3.2 \u00d7 10 -7 ten % 100 s 3.2 \u00d7 10 -6 first % 1 000 s 3.2 \u00d7 10 -5 0.1% Ultimately, if the time to calculate between the two events of interest is one year, then the probability is 100% to make a 3.2 \u00d7 10 error -8 . The probability of committing a given error and the amplitude of this error varies in conversely each other; Another way of presenting things could be to say: If the calculated time is small, then the error may be strong, but the probability of committing it is low, If the calculated time is great, then the probability of committing the error is strong, but the error is low. If this couple (probability of making an error \/ amplitude of the error) is unacceptable, or if we do not know how to assess the impact, then it is surely necessary to ask the question of why we use UTC and what is the need for precision necessary, or to predict the use of tables to be updated as soon as the insertion\/withdrawal of a second interlayer is programmed [ 8 ] , [ 15 ] . UTC Time Conversion in Hour Posix [ modifier | Modifier and code ] Apart from the very rare anomalies mentioned above about the second intercalale, it is easy to convert an UTC hour in an hour posix and vice versa. Example: what is the time POSIX at the very start of the day of the first is January 2009 (line 5 of Table 1 above) : From the POSIX to the time first is January 2009 , 39 years have passed including 10 bissextiles [ 16 ] (see help table below), Or 14,245 days of 24×3,600 = 86,400 seconds each, Or 1,230,768,000 seconds sold since the UNIX era, excluding second intercalale. Table 3: Calculation of the number of days elapsed between first is January 1970 And first is January 2009  Number of days sold 1 970 1 971 1 972 1 973 3*365+366 = 1461 1 974 1 975 1 976 1 977 1461 1 978 1 979 1 980 1 981 1461 1 982 1 983 1 984 1 985 1461 1 986 1 987 1 988 1 989 1461 1 990 1 991 1 992 1 993 1461 1 994 1 995 1 996 1 997 1461 1 998 1999 2 000 2 001 1461 2 002 2 003 2 004 2 005 1461 2 006 2 007 2 008  2*365+366 = 1096  14 245 There are also tools [ 17 ] Who perform these calculations very simply, like this “Shell Script” to convert a second number since the POSIX era in one date: #!\/bin\/sh        # Convert a number of seconds since the POSIX era        #           dated        # Example: Date -u -r -Date \"1970-01-01 1230768000 seconds\"        Date -u -r -Date \"1970-01-01 $* Seconds\" One hour POSIX conversion in UTC hour [ modifier | Modifier and code ] The reverse calculation does not have difficulty, and in the same way there are tools [ 17 ] Who carry out these calculations very simply, like this bash script to convert a date into a number of seconds since the POSIX era: #!\/bin\/sh        # Convert a date (beware in the format of the argument)        # In number of seconds since the POSIX time        # Example: Date-Date \"2009-01-01 00: 00: 00+00: 00\" \"+%S\"        Date -Date \"$*\" \"+%s\" Limited number of years that a particular UNIX system can represent [ modifier | Modifier and code ] The more common method to read the time under Unix, is the call to the following function which returns a type of type “type” time_t\u200b “. time_t time(NULL); This type time_t is commonly used to handle the Unix time, unfortunately the POSIX standard does not specify (clearly) the size: If it’s a 32 -bit machine, time_t will probably be an integer signed 32 bits. This counter allows you to manage a total period of 2 32 seconds, almost 136 years. The most remote date is December 13, 1901 , and the most advanced is January 19, 2038 .  Illustration of the overflow phenomenon. When this most advanced date will be crossed, this representation will overflow (in) , that is to say that it will no longer be able to continue to represent the UNIX time correctly. This problem is called the bug of the year 2038. The animated image opposite illustrates the phenomenon of overflow.  UNIX hour UTC most remote date: -2 thirty first \u22122 147 483 648 1901-12-13 T 20:45:52 Unix era: 0 0 1970-01-01 T 00:00:00 most advanced date: 2 thirty first -first 2 147 483 647 2038-01-19 T 03:14:07 If it’s a 64 -bit machine, time t will probably be an integer signed 64 bits; The limits will then be greater than 292 billion years is much more than the age of our planet or its life expectancy. This impossibility of representation does not necessarily question the functioning of the machine itself, that is to say the functioning of its operating system [ 18 ] But the operation of its applications and interoperability with other machines. Indeed, it is not enough for a machine to locate this limit locally, but all the machines that are connected to it [ 19 ] are able to manage this limit in the same way. Several cases may arise: Either we are dealing with a well -mastered machines park, this is the case for example with embedded systems. In this case, a solution to manage this border can be to ensure that the machine fleet only uses applications developed specially to be robust in the face of this situation [ 20 ] , [ 21 ] , Either we are dealing with a very heterogeneous and not mastered machine park, this is the case, for example, machines from around the world which are connected on the Internet. In this case, a solution would be to generalize the coding of this UNIX hour on 64 bits to all machines, including those in 32 -bit. One can also reasonably hope that all the machines will be at least 64 bits at dawn of 2038. Use of a resolution below the second [ modifier | Modifier and code ] UNIX systems generally maintain a counter whose resolution is finer than the second. This time is accessible by a call to the following function: int gettimeofday(struct timeval *tv, NULL); The numerical value returned by this function is stored in the variable ” struct timeval *tv\u200b \u00bbDefined as follows: Struct Timeval {                int tv_sec; \/ * seconds *\/                int tv_usec; \/ * Microseconds from 0 to 999999 *\/        }; The use of this resolution lower than a second leads to what is happening when a second interlayer is added or entrenched? It seems that this point is the responsibility of the operating system [ 22 ] . In the absence of a clear specification, several scenarios are therefore possible depending on the operating system considered [ 23 ] , [ 24 ] . The three examples below expose the three categories of cases which seem the most representative, they only deal with the insertion aspect of an inter-lap second but they could easily be adapted to the case of deletion: The system clock can be suddenly adjusted by a second, which will give the impression of going back [ 25 ] .  Brutally adjusted time # UTC tv_sec tv_usec  4 2008-12-31T23: 59: 60,000 1 230 768 000 0   2008-12-31T23: 59: 60.500 1 230 768 000 500 000  5 2009-01-01T00: 00: 00.000 1 230 768 000 0 Brutally adjusted time  2009-01-01T00: 00: 00.500 1 230 768 000 500 000  6 2009-01-01T00: 00: 01.000 1 230 768 001 0  The system clock can be kept constant for a second during the insertion of the second interlayer. This means that the time will not go back but will be frozen, as a result the possible impact on applications should be in principle less [ 25 ] .  # UTC tv_sec tv_usec  4 2008-12-31T23: 59: 60,000 1 230 768 000 0   2008-12-31T23: 59: 60.500 1 230 768 000 0 frozen 5 2009-01-01T00: 00: 00.000 1 230 768 000 0 frozen  2009-01-01T00: 00: 00.500 1 230 768 000 500 000  6 2009-01-01T00: 00: 01.000 1 230 768 001 0  The system clock can be slowed down to compensate for the insertion of the second interlayer [ 25 ] .  # UTC tv_sec tv_usec  4 2008-12-31T23: 59: 60,000 1 230 768 000 0   2008-12-31T23: 59: 60.500 1 230 768 000 250 000 Slowed time 5 2009-01-01T00: 00: 00.000 1 230 768 000 500 000 Slowed time  2009-01-01T00: 00: 00.500 1 230 768 000 750 000 Slowed time 6 2009-01-01T00: 00: 01.000 1 230 768 001 0  Use of TAI [ modifier | Modifier and code ] The idea of \u200b\u200busing international atomic time has already been proposed and defended by many people [ 26 ] , but it is not the meaning that was given by history, the chosen choice was that which today is frozen by the POSIX standard. Daniel J. Bernstein has also written articles and software [ 21 ] For the use of TAI on UNIX type systems. Gigaseconde Unix [ modifier | Modifier and code ] The Gigasecond UNIX designates the UNIX 10 time 9 , which represents the September 9, 2001 . \u2191 UNIX time when this page was generated  \u2191 POSIX is a registered trademark of “IEEE”; Unix is \u200b\u200ba registered trademark of “The Open Group”.  \u2191 We can also consult (in)  Epoch time vs. time of day For a discussion on certain legal aspects, and also the other pages of this site; especially (in)  Plots of deltas between time scales To compare the differences between different references.  \u2191 It should not be thought that this list is also short, we can consult (in)  Time Scales For a more exhaustive and precise list.  \u2191 a et b The use of the old standard name “Average time of Greenwich” (GMT, English “Greenwich Mean Time”) is now not recommended because its definition is ambiguous, unlike UTC, which must be preferred to it. This acronym was imposed itself by the preponderance of the British navy during the XIX It is century and was later renamed universal time (UT, from English Universal Time). As UTC time is the civilian time of the meridian origin of longitudes in Greenwich, some have tried to extend the use of GMT by now translating it by “Greenwich Meridian Time” but this semantic shift has no official value.  \u2191 See the article (in)  Greenwich Mean Time | the use of GMT in legislation .  \u2191 In the UTC scale, the seconds and all the other under-multiples (millisecond, microsecond, etc.) are of constant duration, but the minute and all the higher units (time, day, week, etc.) are of variable duration . The addition or suppression of these seconds intercalale is rare, of the order of a second over one to three years. Most UTC days have 86,400 seconds, most hours 3,600 seconds, and most minutes 60 seconds but some may have 86,401 respectively s or 86,399 s , 3 601 s or 3,599 s and 61 s or 59 s .  \u2191 If we traced on a similar graph the difference between UT1 and Tai, we would see UT1 and Tai gradually moving away from each other to the rhythm of the slowdown in the rotation of the earth; Likewise, we would see UTC and Tai moving away from each other by good successive to the rhythm of the addition\/suppression of the second intercalale.  \u2191 A B and C This addition (or deletion) takes place either the end of the last minute of the last day of the month preceding the first is July or the first is January, exceptionally it can be the first is April or the first is October, and is announced 6 months in advance by Irs via its (in)  BULLETIN C – Product metadata . In March 2009, there has never been an abolition of intercalaire seconds, and probably there will never be a matter of the fact that the speed of rotation of the earth inexorably decreases. It may be interesting to consult the other Bulletins of Irs (in)  Irish Bulletins .  \u2191 Future seconds are planned with an anticipation of a maximum of six months, it is the pace to which ISS broadcasts its forecasting bulletin. For past values \u200b\u200bwe can use a table.  \u2191 There is a difficulty with this definition, in the sense that USC did not exist before 1972; This difficulty is bypassed using negative numbers for a date prior to the time; Thus 04-10-1957T00: 00: 00z, 4,472 days before the time, is represented by the time POSIX \u22124 472 \u00d7 86 400 = \u2212386 380 800.  \u2191 See Leap Seconds .  \u2191 a et b A PC is not going to spontaneously slow\/accelerate its internal meter by itself; The adjustment can be made by the user or more likely, if it is connected to the Internet, automatically and almost the Silenting by a clock service, generally it is NTP.  \u2191 The above graph shows that the insertion period of an inter-lap second is between one and three years.  \u2191 The greater the delay, the lower the impact of a second of error and vice versa.  \u2191 For this last method to be used on board an on -board system, this would require the implementation of an automatic and real -time update of the table.  \u2191 One year is bissextile if it is multiple of 4, but not multiple of 100 unless multiple of 400 (example, 2000 was bissextile). The application of this rule shows that it is enough to test the divisibility by 4 between 1901 and 2099.  \u2191 a et b See for example this (in)  Second \/ Date converter .  \u2191 For example, the Linux operating system continues to operate beyond this most advanced date.  \u2191 You have to understand the word connected In the broad sense, this concerns the Ethernet connection, but also the exchange of files via removable discs for which the dating of the files is an important point, for backups for example.  \u2191 We can consult with interest the (in)  Website devoted to the dissemination of information about the bug of the year 2038 which provides a solution to operate until 2106, both on 32 -bit and 64 -bit machines.  \u2191 a et b We can also consider the use of TAI and consult with interest the articles written by D. J. Bernstein on this subject : \u2191 See (in)  The NTP Timescale and Leap Seconds .  \u2191 An article (in)  Leap Second Handling by Operating Systems exhibits 3 possible cases. It is said : ‘ Linux kernels and most other Unix-like systems care about the leap seconds and handle them correctly. \u00bb but without really clarifying what correctly means rightly.  \u2191 See (in)  Five different ways to handle leap seconds with NTP  \u2191 A B and C As an example to assess the impact of these different scenarios, one could imagine a speed measurement instrument which measures the elapsed time for a given distance: in the 3 It is Case, the speed will be overestimated, as much as possible in a report 2, and in the first two cases of a report which may be infinite. We will still remember that the probability of occurrence of such a phenomenon is extremely rare, see above  \u2191 See in particular (in)  History of IEEE P1003.1 POSIX time by Landon Curt Noll\u00a0 (in) .  Related articles [ modifier | Modifier and code ] external links [ modifier | Modifier and code ] Bibliography [ modifier | Modifier and code ]       (adsbygoogle = window.adsbygoogle || []).push({});after-content-x4"},{"@context":"http:\/\/schema.org\/","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"https:\/\/wiki.edu.vn\/all2en\/wiki32\/#breadcrumbitem","name":"Enzyklop\u00e4die"}},{"@type":"ListItem","position":2,"item":{"@id":"https:\/\/wiki.edu.vn\/all2en\/wiki32\/heurre-unix-wikipedia\/#breadcrumbitem","name":"Heurre unix \u2014 wikipedia"}}]}]