1. 65
    The Unix timestamp will begin with 16 this Sunday programming unix unixtimestamp.com
    no_gravity avatar via no_gravity 2 months ago | cached | 14 comments

  1.  

  2. 24
    raymii avatar raymii 2 months ago | link

    Items like these are why I like lobsters. Can’t imagine sending this to my friends, but here, it’s cool.

    1. 12
      susam avatar susam 2 months ago | link

      It is going to be at 2020-09-13 12:26:40 UTC.

      Python:

      $ python3 -q
>>> from datetime import datetime
>>> datetime.utcfromtimestamp(1_600_000_000)
datetime.datetime(2020, 9, 13, 12, 26, 40)

      GNU date (Linux):

      $ date -ud @1600000000
Sun Sep 13 12:26:40 UTC 2020

      BSD date (macOS, FreeBSD, OpenBSD, etc.):

      $ date -ur 1600000000
Sun Sep 13 12:26:40 UTC 2020

      All such dates (in UTC) until the end of the current century:

      $ python3 -q
>>> from datetime import datetime
>>> for t in range(0, 4_200_000_000, 100_000_000): print(f'{t:13_d} - {datetime.utcfromtimestamp(t).strftime("%Y-%m-%d %H:%M:%S")}')
...
            0 - 1970-01-01 00:00:00
  100_000_000 - 1973-03-03 09:46:40
  200_000_000 - 1976-05-03 19:33:20
  300_000_000 - 1979-07-05 05:20:00
  400_000_000 - 1982-09-04 15:06:40
  500_000_000 - 1985-11-05 00:53:20
  600_000_000 - 1989-01-05 10:40:00
  700_000_000 - 1992-03-07 20:26:40
  800_000_000 - 1995-05-09 06:13:20
  900_000_000 - 1998-07-09 16:00:00
1_000_000_000 - 2001-09-09 01:46:40
1_100_000_000 - 2004-11-09 11:33:20
1_200_000_000 - 2008-01-10 21:20:00
1_300_000_000 - 2011-03-13 07:06:40
1_400_000_000 - 2014-05-13 16:53:20
1_500_000_000 - 2017-07-14 02:40:00
1_600_000_000 - 2020-09-13 12:26:40
1_700_000_000 - 2023-11-14 22:13:20
1_800_000_000 - 2027-01-15 08:00:00
1_900_000_000 - 2030-03-17 17:46:40
2_000_000_000 - 2033-05-18 03:33:20
2_100_000_000 - 2036-07-18 13:20:00
2_200_000_000 - 2039-09-18 23:06:40
2_300_000_000 - 2042-11-19 08:53:20
2_400_000_000 - 2046-01-19 18:40:00
2_500_000_000 - 2049-03-22 04:26:40
2_600_000_000 - 2052-05-22 14:13:20
2_700_000_000 - 2055-07-24 00:00:00
2_800_000_000 - 2058-09-23 09:46:40
2_900_000_000 - 2061-11-23 19:33:20
3_000_000_000 - 2065-01-24 05:20:00
3_100_000_000 - 2068-03-26 15:06:40
3_200_000_000 - 2071-05-28 00:53:20
3_300_000_000 - 2074-07-28 10:40:00
3_400_000_000 - 2077-09-27 20:26:40
3_500_000_000 - 2080-11-28 06:13:20
3_600_000_000 - 2084-01-29 16:00:00
3_700_000_000 - 2087-04-01 01:46:40
3_800_000_000 - 2090-06-01 11:33:20
3_900_000_000 - 2093-08-01 21:20:00
4_000_000_000 - 2096-10-02 07:06:40
4_100_000_000 - 2099-12-03 16:53:20
      1. 6
        gerikson avatar gerikson 2 months ago | link

        Specifically on Sun, 13 Sep 2020 12:26:40 UTC.

        1. 5
          caleb avatar caleb 2 months ago | link

          an event of this magnitude happens about every 3.17 years

          1. 5
            ethoh avatar ethoh 2 months ago | link

            Tick, tock, tick, tock.

            The clock is ticking. 2038 approaching.

            The BSDs mostly dealt with this ages ago, but Linux is still not 2038 ready for 32bit architectures (save RV32).

            1. 2
              gerikson avatar gerikson 2 months ago | link

              This patch seems to address the issue for 32-bit Linux systems:

              https://lkml.org/lkml/2020/1/29/355?anz=web

              1. 2
                ethoh avatar ethoh 2 months ago | link

                If you ignore everything else that needs to be done, sure, it does “address the issue”.

                If only if solving the Y2038 problem was as easy as a single kernel patch.

                1. 2
                  gerikson avatar gerikson 2 months ago | link

                  Hopefully more progress will be made in the 18 years remaining.

                  1. 2
                    ethoh avatar ethoh 2 months ago | link

                    They had decades to fix this. They could have e.g. fixed this by Linux 2.0, as they broke everything.

                    The end result is that all sorts of systems made before now (and before it’s fixed, as it still isn’t) will never get updated and will blow up in 2038.

            2. 5
              robey avatar robey 2 months ago | link

              Good riddance to 1.5G. Here’s hoping 1.6G is a happier era!

              1. 5
                jgb avatar jgb 2 months ago | link

                Nice, just 547483648 to go until a round number!

                1. 4
                  kevinc avatar kevinc 2 months ago | link

                  If you’re really psyched about it, you can watch it roll over with this live clock.

                  1. 3
                    markrages avatar markrages 2 months ago | link

                    I still remember the billennium.

                    https://en.m.wikipedia.org/wiki/Unix_time#Notable_events_in_Unix_time

                    1. 1
                      wink avatar wink 2 months ago | link

                      Obligatory trivia that “billion” is really hard for some of us non-native speakers: https://en.m.wikipedia.org/wiki/Long_and_short_scales

                      E.g., a German “Billion” is 1_000_000_000_000 and not a billion, i.e. 1_000_000_000.