Thats Sunday, 13-Sep-20 12:26:40 UTC in RFC 2822
The Unix timestamp will begin with 16 this Sunday
191–200 of 214 posts
Re: The Unix timestamp will begin with 16 this Sunday
#192Avoir 15, you were my favorite time prefix so far :(
> Avoir
You probably meant “Au revoir”. Then again, “Au revoir” means roughly “Until we meet again”, and we won’t be seeing the “15” prefix again.
Re: The Unix timestamp will begin with 16 this Sunday
#193Earlier quoted context omitted.
> Addition and subtraction don't care about unsigned vs signed status, because overflow is identitcal in both cases. Except signed overflow invoking Undefined Behaviour in any C compiler, whereas unsigned overflow does not. This invokes undefined behaviour: foo(int x) { return x + 1 > x; }
We're not talking about C, were talking about how it works on the computers.
Many if not most of the embedded/long term systems are implemented in C. If a variable is declared signed, overflowing cases may and often are "optimized" away.
IIUC, GP's foo() would likely be optimized to { return true; }, and so would similar timestamp overflow checks.
Re: The Unix timestamp will begin with 16 this Sunday
#194https://epochconverter.com is the first bookmark in my bookmark bar, just the icon and no text
I can only recommend using https://epochconverter.com instead of Google's preferred result https://unixtimestamp.com as it automatically detects if milliseconds are included, and it displays the local time more prominently.
Re: The Unix timestamp will begin with 16 this Sunday
#195Earlier quoted context omitted.
Fire, then Deepness, then stop.
Or Fire , then The Peace War . Maybe dip into True Names , followed by Shockwave Rider by John Brunner. Many people didn't like Deepness much. But the sequel to Fire, Children of the Sky , was interesting.
For me A Deepness in the Sky is his best, and one of the most memorable novels I've read.
The Peace War is a fascinating exploration of "what if this one thing was possible?" and all its terrible consequences, but Deepness grabbed me much more as a story.
Re: The Unix timestamp will begin with 16 this Sunday
#196I make a bold prediction that we'll run out of digits rather soon.
2037 is a potential overflow, I believe. I imagine only pre 2000 systems would likely be affected.
2038 is when signed 32-bit ints overflow. That's only running out of binary digits though, not decimal like the event under discussion.
In [1]: import datetime
In [2]: datetime.datetime.utcfromtimestamp(2**31)
Out[2]: datetime.datetime(2038, 1, 19, 3, 14, 8)Re: The Unix timestamp will begin with 16 this Sunday
#197Earlier quoted context omitted.
> Addition and subtraction don't care about unsigned vs signed status, because overflow is identitcal in both cases. Except signed overflow invoking Undefined Behaviour in any C compiler, whereas unsigned overflow does not. This invokes undefined behaviour: foo(int x) { return x + 1 > x; }
We're not talking about C, were talking about how it works on the computers.
But because the behaviour is undefined, it doesn't matter how the computer would handle it, because the compiler is free to rework it into any arbitrary sequence of instructions, including removing it altogether.
Re: The Unix timestamp will begin with 16 this Sunday
#198Earlier quoted context omitted.
I was involved in building a system using 32-bit ints as timestamps ten years ago. They are still sold, and since it's industrial equipment running on 16 bit microcontrollers I have every reason to believe most of them will still be around in 2038. I don't think I was at the only company doing this. Few people seem to care about issues that will happen after their retirement. Expect lots of industrial stuff to work j…
Why will PIC's fail sooner? (and which ones, 8, 16 or 32bit?)
I worked with the 16 bit PIC24f. I don't have the source handy to check, but according to a forum entry "The provided gmtime() actually fails earlier than 2038. The year wraps around when the time_t input goes beyond 0x7C55817F or Thu Feb 7 06:28:15 2036." [1]
Re: The Unix timestamp will begin with 16 this Sunday
#199I remember staying up late (UK) at the Billenium (2:46 AM Sunday Sep 9th 2001), thinking that was bound to be the most newsworthy event of the week, watching the seconds tick past on a "while(sleep 1); do date" loop, with slashdot in one window, IRC in another, all running on an enlightenment window manager. 500M seconds later I was in Washington DC in a hotel, watching it tick up on an rxvt on my laptop, with HN in…
I’m currently on an iPhone 7S. I’ve got a mosh session open to a remote raspberry pi 4B (time looks right), bash shell, “while(sleep 1); do date +%s”, running in Blink SSH while I read HN cause I couldn’t sleep. Have an alarm set for 12:26 UTC so I can grab that screenshot. Following along with you :)
Re: The Unix timestamp will begin with 16 this Sunday
#200I remember staying up late (UK) at the Billenium (2:46 AM Sunday Sep 9th 2001), thinking that was bound to be the most newsworthy event of the week, watching the seconds tick past on a "while(sleep 1); do date" loop, with slashdot in one window, IRC in another, all running on an enlightenment window manager. 500M seconds later I was in Washington DC in a hotel, watching it tick up on an rxvt on my laptop, with HN in…
(guenine curiosity) Why do you wait for these events ? Myself I consider these to be complete non-events.
You got downvoted for this question but it’s such a great question in this context because like the UNIX epoch, the answer is arbitrary :)
Incidentally, I guess the windows/NT epoch started in 1601.