5 ms·

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) date

• nvrspyx 6y ago
  To add, Powershell: (Get-Date "1/1/1970").AddSeconds(1600000000).ToUniversalTime() or alternatively for your local time: (Get-Date "1/1/1970").AddSeconds(1600000000).ToLocalTime()
  • netmare 6y ago
    Heh... I've run into this bug myself recently. Get-Date '...' returns a DateTime object of Unspecified kind, i.e. neither Local nor Utc. By design, such objects are interpreted as Local by ToUniversalTime() and as Utc by ToLocalTime(). They essentially assume the inverse of themselves, for better or worse. Since the Kind property is readonly, to get the real UTC date you need: $naive = (Get-Date "1/1/1970").AddSeconds(1600000000) $local = $naive.ToLocalTime() $utc = $local.ToUniversalTime()
    • nvrspyx 6y ago
      Interesting. I'm using Powershell 7 (e.g. Powershell Core) and I'm not sure exactly which version number specifically, but the functions seem to work as intended on my Windows 10 machine.
    • jasomill 6y ago
      Or, equivalently, $utc = [DateTimeOffset]::FromUnixTimeSeconds(16e8).UtcDateTime Incidentally, PS> ($utc, (Get-Date -AsUtc '1/1/1970'), (Get-Date -AsUtc), (Get-Date)).Kind Utc Utc Utc Local In your example, $naive.Kind -eq [DateTimeKind]::Unspecified correctly, because no DateTimeKind was specified. The peculiar behavior you observed with ToLocationTime and ToUniversalTime exists to avoid breaking changes in working[1] code written for versions of the .NET Framework before 2.0, where DateTime.Kind was introduced (as was DateTimeOffset, so ToLocationTime and ToUniversalTime should probably be deprecated). [1] "Breaking" changes exist for already-broken code, e.g., in Framework 2.0 and later, the return values of ToUniversalTime and ToLocalTime have Kinds Utc and Local, respectively, so applying the same conversion to an already-converted value no longer has any effect.
• LeoPanthera 6y ago
  Omit the "u" to see the result in local time, not UTC.
  • themattmans 6y ago
    Thank you both. I was looking for the right combination of flags and realized that the date(1) man page is far too dense for simple tasks like this. $ date -r 1600000000 Sun Sep 13 05:26:40 PDT 2020
• ericbarrett 6y ago
  The datetime package is one of the best things about Python, and dare I say one of the best general purpose calendar modules ever written. It’s just so practical.
  • BrandoElFollito 6y ago
    arrow (my favorite), pendulum or delorean are in my opinion much better (= easier to use, versatile, ...)
  • sltkr 6y ago
    Python is great, but in this case, you could get almost identical output using bash alone: for t in {0..4100000000..100000000}; do TZ=UTC printf "%'13d - %(%Y-%m-%d %H:%M:%S)T\n" $t $t; done
  • wwright 6y ago
    It still can’t parse ISO8601 :(
    • larkeith 6y ago
      `datetime.fromisoformat()`, as of 3.7 :D Though `dateutil` is still recommended for most cases.
      • wwright 6y ago
        That parses a subset and is only guaranteed to be compatible with Python’s “.toisoformat()”. (I imagine it would be backwards compatible to expand it to cover all of ISO8601 and I can’t tell why they haven’t.)
        • londt8 6y ago
          ISO8601 is quite large, they probably don't want to ship that big standard library modules which would parse 100% of ISO8601
  • X6S1x6Okd1st 6y ago
• robk 6y ago
  It made me feel better doing the math I'm likely to be alive for 3,000,000,000
  • adtac 6y ago
    depends on how apocalyptic Y2038 is :)
    • larkeith 6y ago
      Or the rest of Y2020, for that matter.
• dylan604 6y ago
  > 4_100_000_000 - 2099-12-03 16:53:20 We're going to party like it's 2099! Watch out for that Y2K+100 bug!!
• leowoo91 6y ago
  I can already hear people from 2033 celebrating 2b..
• JdeBP 6y ago
  That's the point that your library's time_t reaches those values. But the point at which you will be 1.6Gs since the Unix v4 Epoch is in fact 27 seconds earlier, because your time_t hasn't counted the leap seconds over that period. To do that with Unix tools, you need to work with TAI timekeeping, not UTC, and remember that the (biased) zero point for TAI timekeeping is 10s before the Unix v4 Epoch. % jot - 10 20 | while read -r d do printf "@40000000%08x%08x %s00Ms SI since the Unix v4 Epoch\n" \ "$d"00000010 0 "$d" done | TZ=right/UTC tai64nlocal 2001-09-09 01:46:18.000000000 1000Ms SI since the Unix v4 Epoch 2004-11-09 11:32:58.000000000 1100Ms SI since the Unix v4 Epoch 2008-01-10 21:19:37.000000000 1200Ms SI since the Unix v4 Epoch 2011-03-13 07:06:16.000000000 1300Ms SI since the Unix v4 Epoch 2014-05-13 16:52:55.000000000 1400Ms SI since the Unix v4 Epoch 2017-07-14 02:39:33.000000000 1500Ms SI since the Unix v4 Epoch 2020-09-13 12:26:13.000000000 1600Ms SI since the Unix v4 Epoch 2023-11-14 22:12:53.000000000 1700Ms SI since the Unix v4 Epoch 2027-01-15 07:59:33.000000000 1800Ms SI since the Unix v4 Epoch 2030-03-17 17:46:13.000000000 1900Ms SI since the Unix v4 Epoch 2033-05-18 03:32:53.000000000 2000Ms SI since the Unix v4 Epoch % Also, your figures for 0.0Gs and 0.1Gs are nonsense anyway. Unix didn't adopt this Epoch and method of timekeeping until 4th Edition, somewhere in 1974 according to Unix historians. Yes, it's tricky to pin down the exact date of adoption. The Epoch was changed every year before then, as earlier versions of Unix measured time in 60ths of a second since the start of the year. This has made reconstructing Unix history from tape archives non-trivial. If you want to count seconds since the start of the first Unix Epoch, in 1st Edition, you have to count from the start of 1971. And no, that's not the same as how old Unix is. (And yes, those values for 2023 onwards are somewhat speculative, as there will no doubt be more leap seconds.)