5 ms·

UTC vs. UT1 time and other nuances (2020)

• layer8 4y ago
  TAI is also a kind of approximation, since time elapses differently depending on gravitational pull, due to relativistic effects. It is defined as the physical time elapsing on a geodesic, an imaginary surface covering the earth at roughly sea level with equal gravitational pull at all points. In reality, physical time elapses at slightly different “rate” depending on where you’re located on the surface of the earth (or possibly not on the surface of the earth), also due to nonuniformities in the earth’s mantle affecting the gravitational field. TAI is taken as the average between the 400-or-so contributing atomic clocks, adjusted for their relative height above sea level, and possibly other factors, and taking into account the signal propagation time between the clocks. Compared to the time in the reference frame of the sun, for example, (which may be taken as a solar-system wide time-keeping standard) TAI wiggles around that solar time according to earth’s yearly cycle around the sun. Of course, those variations are much smaller than DUT1 (at least close to earth’s reference frame).
  • sxcurry 4y ago
    Rather than geodesic I think you meant geoid.
    • layer8 4y ago
      You’re right of course, can’t edit it anymore.
  • tvb 4y ago
    TAI and UTC are based on the SI second. The SI second is specifically defined in terms of cesium atoms at no temperature, no velocity, and no elevation (aka, on the geoid). Consequently TAI and UTC are immune from relativistic effects, by definition. On the other hand, the physical clocks in the laboratory are not immune and that's why they have to be corrected for a dozen factors, the largest of which is usually gravitational redshift. To appreciate the complexity and precision of this correction see this NIST paper: https://tf.nist.gov/general/pdf/2883.pdf https://tf.nist.gov/general/pdf/2883.pdf
    • pdonis 4y ago
      > TAI and UTC are based on the SI second. The SI second is specifically defined in terms of cesium atoms at no temperature, no velocity, and no elevation (aka, on the geoid). Consequently TAI and UTC are immune from relativistic effects, by definition. This is not quite correct. The definition of the SI second does not make any requirements or assumptions about the state of motion or location of the cesium atoms. The only requirement is that the device that measures the frequency of the cesium atom hyperfine transition is at rest relative to the atoms themselves and spatially co-located with them. That is what ensures that no relativistic effects are involved in the measurement. The definitions of TAI and UTC are not simply based on the SI second, but on the SI second as recorded by clocks on the geoid that are at rest relative to the rotating Earth. That extra qualifier is why measurements recorded by clocks not on the geoid have to be adjusted.
    • thethirdone 4y ago
      The current SI second[0] does not make any mention of Earth. Elevation does not factor into the definition. [0]: https://www.bipm.org/documents/20126/41483022/SI-Brochure-9-EN.pdf https://www.bipm.org/documents/20126/41483022/SI-Brochure-9-... page 16
    • throwaway09223 4y ago
      I think you might be misunderstanding. Clocks must necessarily have a frame of reference. TAI's frame of reference is imaginary (geoid), and in reality we calculate it from an average. Because TAI's frame of reference is the geoid it will experience relativistic effects based on earth's motion viewed from any other frame of reference (in OP's example, from the reference of the sun) Clocks cannot exist without a frame of reference. Accurate timekeeping necessarily involves tracking spatial information as well.
  • deleted 4y ago
    [deleted]
• deleted 4y ago
  [deleted]
• euroderf 4y ago
  How in the world did astronomers & their software developers manage to push off onto the rest of the software world (and society at large) the atrocious concept of leap seconds.
  • jabl 4y ago
    UT1 might not work for engineering applications with tight tolerances, as the length of a UT1 second varies. Personally, in my non-expert opinion, we should stop adding or subtracting leap seconds from UTC (that is, UTC would thereafter be at a constant offset from TAI), and leap seconds would instead be added to the timezone DB. That way local time (like Aug 14 2022 xx:53) would still retain the familiarity with 12:00 being noon, at least at some point in each timezone, but calculations with UTC seconds would not need to bother with leap seconds.
    • blahgeek 4y ago
      I think the problem is that we already have the networks and protocols to synchronize time (NTP, PTP, etc.), but not for timezone DB data.
      • mlichvar 4y ago
        RFC 7808 specifies a TZDIST service. But most operating systems already have their own mechanism to update their timezone database. This is not a problem. Shifting timezones by 15 minutes every few thousand years would work with current software. All we need to do is to agree that UTC will have no more leap seconds.
    • bloak 4y ago
      If people don't like leap seconds, there is no need to redefine UTC; they can just use TAI today. That gives them the additional advantage of not having to handle leap seconds in the past, because software that handles historical UTC timestamps will always need to know about the leap seconds that have already happened.
      • 4y ago
• bxparks 4y ago
  Even more confusing, the time printed by our computers may appear to be UTC, but is probably POSIX (or Unix) time. It is very close to UTC but ignores leap seconds. https://en.wikipedia.org/wiki/Unix_time https://en.wikipedia.org/wiki/Unix_time During a positive leap second, the POSIX second repeats itself (an alternative mental model could be that the given POSIX-second lasts 2 UTC-seconds). During a negative leap second, the given POSIX-second disappears (or alternatively, the given POSIX-second lasts 0 UTC-seconds). On my Ubuntu box, the `date +%s` command prints the number of POSIX seconds since 1970-01-01, not the number of UTC seconds since 1970-01-01. To get the number of UTC seconds, we must add the number of intervening leap seconds since 1970-01-01. I get a headache every time I have to think about this.
  • jillesvangurp 4y ago
    Your computer periodically syncs with other computers to compensate for the time drift. Posix is just an API and a set of conventions. What your computer syncs with (typically via NTP), is a bunch of very precise clocks. Without that, you'd have a lot of time drift. The reason POSIX ignores leap seconds is because a leap second is well below the margin of error that most computer clocks have. They simply are not precise enough. Without syncing they'd be drifting apart many seconds within days/weeks probably. That's also why the leap second correction is not a big deal because it just happens when computers sync. A few seconds correction is just a routine correction. Happens all the time.
    • jeroenhd 4y ago
      This is also why I think it's silly people make such a big deal out of leap seconds. Yes, to the programmers it would be great if time were to flow uniformly, but it doesn't, and it doesn't even stay consistent on your computer. Your time may go back and forth several seconds depending on your RTC and its conditions and leap seconds should be treated the same.
    • zokier 4y ago
      The reason why POSIX time ignores leap seconds was that it was considered simpler for userspace if you can do things like `time() % 86400` to get the time of day etc without needing to worry about leap seconds, essentially allowing userspace to be ignorant of leap seconds.
• denton-scratch 4y ago
  > Essentially, UTC is a compromise devised to satisfy the needs of two communities of users:* Astronomers and navigators, * Physicists and engineers I think author is wrong about astronomers, for whom UTC is an unwanted complication. Astronomers use sidereal time, which is unrelated to ther apparent motion of the sun. For short intervals, physicists and engineers may as well use atomic time. The WP article on UTC has a section titled "Rationale", but doesn't explain what problems/compromises UTC was supposed to address. It's worthy of note, however, that of the three bodies involved in the first version of UTC, two were national naval observatories.
  • welterde 4y ago
    UT1 (and therefore UTC) is however a better starting point for calculating the sidereal time than TAI since it is connected to the rotation of the Earth, whereas TAI is not. This way the relation to calculate the (L)ST only depends on fixed constants and the time and date. Also UT1 is actually measured based on distant celestial objects, because it is easier to measure those at very high precision than the precise transit time of the Sun.
    • nullc 4y ago
      That depends on if UTC alone is an accurate enough estimate of UT1 for you. If you only need to know UT1 to within +/- 0.9 seconds, then you can just use UTC and you're done. If you'd like greater accuracy, UTC isn't a great starting point because UTC's leap seconds complicate getting an accurate estimate of UT1. Its hard to tell if your local idea of UTC has had the latest leap second applied or has had false leap seconds applied (or worse, accidentally received a leap smeared source, which can't be backed out to convert to UT1). If you're going to produce a more accurate estimate of UT1 either using interpolations of IERS bulletin B predictions or a model based on the daily USNO ultra-rapid UT1 VLBI measurements the leap seconds don't do anything to help you, but they can mess up your calculations because you need to correctly and consistently back them out. So essentially the practice of leap seconds helps applications that need UT1 to within better than an hour or two (otherwise just using TAI with offset or TAI plus a static linear correction is good for thousand of years), but hurts applications that need subsecond UT1 accuracy, hurts anyone that needs consistent or accurate duration, and creates a lot of software bugs including ones that can show up when there hasn't actually been a leap second. I would argue that today the number of applications that need UT1 at all are much smaller and less significant than ones that need subsecond consistent durations or times. And that of the applications that want UT1 most either don't need leapseconds at all (e.g. TAI or TAI plus the simplest static linear correction is enough) or would prefer better than 1 second accuracy, where at best leapseconds don't help and in practice they add a lot of complexity and still sometimes cause failure.
• welterde 4y ago
  The author argues that only TAI would make sense to an alien civilization, but I don't think that's true at all. I think they miss the fact that it also is only defined within the reference frame of the Earth and also that it depends on many technically subtle aspects. Especially if one only wants to communicate times between the civilizations, such as meet here at 13:00 in exactly three years from now. This is much easier to communicate based on rotation angles of the Earth than on a atomic time scale that would need to be transferred very precisely to be useful at all.
• dsq 4y ago
  After reading the comments, it seems to me a theme is that everyone thinks somebody else is mistaken or misunderstanding the subject. This is not a complaint, but an observation on how difficult and slippery this subject is! I, at least, hardly understand it at all.
• tengwar2 4y ago
  Unfortunately this continues the perception that UTC/GMT is a time zone. It isn't. A time zone is a geographical area where all the clocks show the same time, but the time that they show may vary - for instance, despite Microsoft's insistence, the UK is not in the "UTC timezone". This may seem pedantic, and most of the time it's not important to understand the difference. But when this misunderstanding bites, it will take your leg off at the knee.