7 ms·

next one is in 3 years

SamBam 3y ago
Set a calendar notification for Friday, January 15, 2027 8:00:00 AM GMT. Woah, is that weird that it's exactly on the hour? ...I guess not so weird, since 180 is divisible by 60.
- radarsat1 3y ago
  Does that mean unix date calculations do not take into account the leap second? https://en.m.wikipedia.org/wiki/Leap_second https://en.m.wikipedia.org/wiki/Leap_second
  - deepsun 3y ago
    And it's intentional, so each day has exactly 86400 seconds, even though it doesn't correspond to UTC. In fact, UTC will change its leap second logic much sooner than Unix time logic, so UTC logic will be more like Unix time.
    - usrbinbash 3y ago
      > In fact, UTC will change its leap second logic much sooner than Unix time logic, so UTC logic will be more like Unix time. This. If anyone is interested in a source: https://www.scientificamerican.com/article/the-leap-seconds-time-is-up-world-votes-to-stop-pausing-clocks/ https://www.scientificamerican.com/article/the-leap-seconds-...
  - jolmg 3y ago
    https://unix.stackexchange.com/questions/758932/unix-time-leap-seconds-and-converting-unix-time-to-a-date https://unix.stackexchange.com/questions/758932/unix-time-le...
  - finnh 3y ago
    That's a long page, but basically the answer is no. We don't randomly have a 61 second minute in "clock" units; instead we have a day that takes 86401 _real_ seconds but only the standard 86400 clock seconds. By way of analogy, imagine we implemented leap years by slowing our clocks to half speed on Feb 28 instead of adding a Feb 29.
    - cryptoz 3y ago
      > imagine we implemented leap years by slowing our clocks to half speed on Feb 28 instead of adding a Feb 29 Thanks I will imagine this! Too bad we can’t slow the real Earth time down and have a bizarrely slow and long day every 4 years.
      - fooker 3y ago
        Leap hours would be neat!
        petre 3y ago
        Not if you write code that calculates time.
        ASalazarMX 3y ago
        I guess that would still be neat when finished.
        firecall 3y ago
        I guess it wouldn’t matter if the code was calculating time offsets and so on. But it would matter if I wanted something to take 60mins and then set a start time and an end time. Dates and timezones are the worst! :-)
        GauntletWizard 3y ago
        We had one of those last weekend (At least in most of the US)
  - syncsynchalt 3y ago
    They do not, no. You can do things like find midnight GMT by checking (t % 86400 == 0) for example.
  - linsomniac 3y ago
    Unix time is the number of seconds since Jan 1, 1970 00:00:00 UTC. This number never goes back or forward, it's simply the number of Mississippis you would have counted if you started Jan 1, 1970 at 00:00:00 UTC. When you run "date", it asks the system for this number of seconds, then uses a database to look up what that number corresponds to in the local timezone, accounting for leap years and seconds, and spits out that value. So when (some of us) recently "fell behind", the Unix time incremented by 1 second, but that database told us that the time had decreased by an hour. Not exactly sure how Windows does it, but I recently set up monitoring of a job that Task Scheduler runs, starting at midnight and running for 1 day, every 5 minutes. I got paged at 11:30 because the scheduler decided "1 day" is "24 hours", and it stopped running it at 11pm because of the time change, but didn't start the one for the next day. I know cron can be confusing, but I'll take it any day over this.
    - zokier 3y ago
      > Unix time is the number of seconds since Jan 1, 1970 00:00:00 UTC. This number never goes back or forward, it's simply the number of Mississippis you would have counted if you started Jan 1, 1970 at 00:00:00 UTC. Wrong. UNIX time is number of days since epoch × 86400 + seconds since beginning of day. In real world some days have been actually 86401 seconds long, which means that UNIX timestamp is (currently) 37 less than number of seconds since epoch.
      - ThePowerOfFuet 3y ago
        Then parent was correct but `s/UTC/TAI/g`; no counting of days nor multiplication required.
        SAI_Peregrinus 3y ago
        Exactly. UNIX time, GPS time, and TAI are a fixed offset from one another. They're a variable offset from UT1 (based on earth's angle with respect to some distant quasars). If you care about things like where the stars are, use UT1. If you want monotonic time, use TAI or one of the time standards that's a fixed offset from it. If you want to plan a spacecraft trajectory through the solar system, use barycentric coordinate time (TCB). If you want something that approximates UT1 but otherwise works like TAI, use UTC. If you're dealing with human activity, UTC will usually be the easiest choice. If you're just dealing with computers, TAI (or one of its fixed-offset variants like UNIX time) will usually be the easiest choice.

Set a calendar notification for Friday, January 15, 2027 8:00:00 AM GMT. Woah, is that weird that it's exactly on the hour? ...I guess not so weird, since 180 is divisible by 60.

radarsat1 3y ago
Does that mean unix date calculations do not take into account the leap second? https://en.m.wikipedia.org/wiki/Leap_second https://en.m.wikipedia.org/wiki/Leap_second
- deepsun 3y ago
  And it's intentional, so each day has exactly 86400 seconds, even though it doesn't correspond to UTC. In fact, UTC will change its leap second logic much sooner than Unix time logic, so UTC logic will be more like Unix time.
  - usrbinbash 3y ago
    > In fact, UTC will change its leap second logic much sooner than Unix time logic, so UTC logic will be more like Unix time. This. If anyone is interested in a source: https://www.scientificamerican.com/article/the-leap-seconds-time-is-up-world-votes-to-stop-pausing-clocks/ https://www.scientificamerican.com/article/the-leap-seconds-...
- jolmg 3y ago
  https://unix.stackexchange.com/questions/758932/unix-time-leap-seconds-and-converting-unix-time-to-a-date https://unix.stackexchange.com/questions/758932/unix-time-le...
- finnh 3y ago
  That's a long page, but basically the answer is no. We don't randomly have a 61 second minute in "clock" units; instead we have a day that takes 86401 _real_ seconds but only the standard 86400 clock seconds. By way of analogy, imagine we implemented leap years by slowing our clocks to half speed on Feb 28 instead of adding a Feb 29.
  - cryptoz 3y ago
    > imagine we implemented leap years by slowing our clocks to half speed on Feb 28 instead of adding a Feb 29 Thanks I will imagine this! Too bad we can’t slow the real Earth time down and have a bizarrely slow and long day every 4 years.
    - fooker 3y ago
      Leap hours would be neat!
      - petre 3y ago
        Not if you write code that calculates time.
        ASalazarMX 3y ago
        I guess that would still be neat when finished.
        firecall 3y ago
        I guess it wouldn’t matter if the code was calculating time offsets and so on. But it would matter if I wanted something to take 60mins and then set a start time and an end time. Dates and timezones are the worst! :-)
      - GauntletWizard 3y ago
        We had one of those last weekend (At least in most of the US)
- syncsynchalt 3y ago
  They do not, no. You can do things like find midnight GMT by checking (t % 86400 == 0) for example.
- linsomniac 3y ago
  Unix time is the number of seconds since Jan 1, 1970 00:00:00 UTC. This number never goes back or forward, it's simply the number of Mississippis you would have counted if you started Jan 1, 1970 at 00:00:00 UTC. When you run "date", it asks the system for this number of seconds, then uses a database to look up what that number corresponds to in the local timezone, accounting for leap years and seconds, and spits out that value. So when (some of us) recently "fell behind", the Unix time incremented by 1 second, but that database told us that the time had decreased by an hour. Not exactly sure how Windows does it, but I recently set up monitoring of a job that Task Scheduler runs, starting at midnight and running for 1 day, every 5 minutes. I got paged at 11:30 because the scheduler decided "1 day" is "24 hours", and it stopped running it at 11pm because of the time change, but didn't start the one for the next day. I know cron can be confusing, but I'll take it any day over this.
  - zokier 3y ago
    > Unix time is the number of seconds since Jan 1, 1970 00:00:00 UTC. This number never goes back or forward, it's simply the number of Mississippis you would have counted if you started Jan 1, 1970 at 00:00:00 UTC. Wrong. UNIX time is number of days since epoch × 86400 + seconds since beginning of day. In real world some days have been actually 86401 seconds long, which means that UNIX timestamp is (currently) 37 less than number of seconds since epoch.
    - ThePowerOfFuet 3y ago
      Then parent was correct but `s/UTC/TAI/g`; no counting of days nor multiplication required.
      - SAI_Peregrinus 3y ago
        Exactly. UNIX time, GPS time, and TAI are a fixed offset from one another. They're a variable offset from UT1 (based on earth's angle with respect to some distant quasars). If you care about things like where the stars are, use UT1. If you want monotonic time, use TAI or one of the time standards that's a fixed offset from it. If you want to plan a spacecraft trajectory through the solar system, use barycentric coordinate time (TCB). If you want something that approximates UT1 but otherwise works like TAI, use UTC. If you're dealing with human activity, UTC will usually be the easiest choice. If you're just dealing with computers, TAI (or one of its fixed-offset variants like UNIX time) will usually be the easiest choice.