I 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.<p>500M seconds later I was in Washington DC in a hotel, watching it tick up on an rxvt on my laptop, with HN in a window.<p>Who knows where I'll be in 2033, hopefully not in Europe as I'll be too old for night shifts, but wherever I am, I suspect it will have a bash prompt.
When we one day become a space faring civilization we will probably stop using the gregorian calendar because why would you use that on say Mars?<p>But there really is no reason to get rid of the unix timestamp as a measure of time and this measure may stay around for a long time. This may mean that people in the future might consider 1970 as year zero where modern civilization began.
I hope you are running an up-to-date Splunk version:<p>Beginning on September 13, 2020 at 12:26:39 PM Coordinated Universal Time (UTC), un-patched Splunk platform instances will be unable to recognize timestamps from events with dates that are based on Unix time, due to incorrect parsing of timestamp data.<p><a href="https://docs.splunk.com/Documentation/Splunk/latest/ReleaseNotes/FixDatetimexml2020" rel="nofollow">https://docs.splunk.com/Documentation/Splunk/latest/ReleaseN...</a>
All dates describing pattern:<p>code:<p>#!/bin/bash<p>for t in $(seq 0 100000000 $((2* * 31))); do date -u -d @$t +'%s -> %c'; done<p>output:<p>0 -> Do 01 Jan 1970 00:00:00 UTC<p>100000000 -> Sa 03 Mär 1973 09:46:40 UTC<p>200000000 -> Mo 03 Mai 1976 19:33:20 UTC<p>300000000 -> Do 05 Jul 1979 05:20:00 UTC<p>400000000 -> Sa 04 Sep 1982 15:06:40 UTC<p>500000000 -> Di 05 Nov 1985 00:53:20 UTC<p>600000000 -> Do 05 Jan 1989 10:40:00 UTC<p>700000000 -> Sa 07 Mär 1992 20:26:40 UTC<p>800000000 -> Di 09 Mai 1995 06:13:20 UTC<p>900000000 -> Do 09 Jul 1998 16:00:00 UTC<p>1000000000 -> So 09 Sep 2001 01:46:40 UTC<p>1100000000 -> Di 09 Nov 2004 11:33:20 UTC<p>1200000000 -> Do 10 Jan 2008 21:20:00 UTC<p>1300000000 -> So 13 Mär 2011 07:06:40 UTC<p>1400000000 -> Di 13 Mai 2014 16:53:20 UTC<p>1500000000 -> Fr 14 Jul 2017 02:40:00 UTC<p>1600000000 -> So 13 Sep 2020 12:26:40 UTC<p>1700000000 -> Di 14 Nov 2023 22:13:20 UTC<p>1800000000 -> Fr 15 Jan 2027 08:00:00 UTC<p>1900000000 -> So 17 Mär 2030 17:46:40 UTC<p>2000000000 -> Mi 18 Mai 2033 03:33:20 UTC<p>2100000000 -> Fr 18 Jul 2036 13:20:00 UTC<p>--------------------------------------------------------------<p>overflow of currently used datatype for timer happening at:<p>code:<p>#!/bin/bash
date -u -d @2147483648 +'%s -> %c'<p>output:<p>2147483648 -> Di 19 Jan 2038 03:14:08 UTC<p>info:<p><a href="https://en.wikipedia.org/wiki/Year_2038_problem" rel="nofollow">https://en.wikipedia.org/wiki/Year_2038_problem</a><p>--------------------------------------------------------------<p>other interesting date:<p>pi day:<p>date -u -d @3141592653 +'%s -> %c'<p>3141592653 -> So 21 Jul 2069 00:37:33 UTC (100th birthday for moonlanding mission on pi-day/sec)
The crazy thing is there has <i>only</i> been 1.6 billion seconds since 1970. There have been more babies since 1970 than there have been seconds. Which is crazy.<p>Back then, Earth's population was on 3.7 billion. Now it's 7.8 billion. That means that (ignoring deaths) 2.5 babies have been born for each unix second. Or roughly 1 baby every 400 milliseconds.
I enjoyed the lunch party we threw at work when it hit 1234567890.<p>I worked in Corporate IT at the time, so most of the office had no idea what we were celebrating. Somehow, neither did 80% of the tech staff. But the few of us who appreciated it really enjoyed the cake.
I have a twitter bot called time_t_emit that tweets palindromic seconds since the epoch. (somewhat inspired by the now defunct @megasecond)<p><a href="https://twitter.com/time_t_emit" rel="nofollow">https://twitter.com/time_t_emit</a><p>It's going to tweet twice tomorrow at lunch time (in my time zone) either side of the rollover.<p>I fondly remember the gigasecond party I went to with a load of friends - it happened in the small hours on Sunday morning, ideal party time for a bunch of geeks in their 20s, like an extra new year's eve!
Gif recording of this
<a href="https://media.giphy.com/media/MDxNo8cSBDHYTGLdC2/giphy.gif" rel="nofollow">https://media.giphy.com/media/MDxNo8cSBDHYTGLdC2/giphy.gif</a>
<a href="https://epochconverter.com" rel="nofollow">https://epochconverter.com</a> is the first bookmark in my bookmark bar, just the icon and no text<p>I can only recommend using <a href="https://epochconverter.com" rel="nofollow">https://epochconverter.com</a> instead of Google's preferred result <a href="https://unixtimestamp.com" rel="nofollow">https://unixtimestamp.com</a> as it automatically detects if milliseconds are included, and it displays the local time more prominently.
Tangentially related, last week I made a tiny one-file Java lib for working with Unix timestamps in milliseconds (as returned by System.currentTimeMillis() etc). It’s several orders of magnitude faster that Java’s time api!<p><a href="https://github.com/williame/TimeMillis" rel="nofollow">https://github.com/williame/TimeMillis</a><p>It’s probably not as fast as it could be: all speed ups and improvements welcome!
weird Q I was wondering about in regards to the epoch. (perhaps a stupid Q)<p>what would be the problems with choosing a new epoch (i.e. one where jan 1 is the same day of week as jan 1, 1970 and is 2 years before a leap year. (perhaps doesn't exist).<p>The worse case I see is that apps that calculate years internally (instead of via a shared library or like) would calculate them incorrectly. I'm wondering if this wouldn't be something that could be massaged around. Of course, it just pushes the problem down the road.<p>it also makes timestamps like this incompatible between systems that have different epochs, which could be an issue.<p>as I said, naive (possibly stupid) Q, just wondering if people have actually talked about it?
From the, "I don't know who needs to desperately update their automated scripts..." dept. :rofl_emoticon:[0]<p>[0] Yes, I know this doesn't get transformed here.