Unix time is awful, since converting it to UTC is a real pain, as it doesn't count leap seconds which are included in UTC (thus, some seconds in Unix time are longer than others, or all of them are longer than standard SI seconds and the exact length fluctuates based on the introduction of leap seconds, or the like).
What else other than leap seconds are you referring to? Leap seconds are a problem for all time storage since most time parsers consider second 61 invalid [1]. They also only happen about once a year. Google just pretends they don't exist [2].
Converting from epoch to the local timezone is supported in pretty much every language. I'm not sure why you think it's such a pain.
The "or the like" was the end of the list of ways in which you could model the divergence between Unix time and the number of SI seconds between January 1st 1970 UTC and the present.
One way of modelling it is as saying that seconds in Unix time all have the same length, that differs by some factor from SI seconds, though that factor changes every time a leap second is introduced.
Another way is to say that seconds don't all have constant length; some seconds have a different length than the rest of the seconds (like those in the hour or day leading up to a leap second, or even just that the one second before the leap second is twice as long as a regular second).
The "or the like" was just a hedge against other possible ways of describing this divergence that I hadn't described in that one quick sentence.
Pretending that leap seconds don't exist is all well and good if you have a completely closed system, but as soon as you try to synchronize with or compare timestamps with UTC, you'll start running into problems.
How is Google's leap smear idea pretending like leap seconds don't exist? As per your link, "The solution we came up with came to be known as the “leap smear.” We modified our internal NTP servers to gradually add a couple of milliseconds to every update, varying over a time window before the moment when the leap second actually happens."
> Usually when a leap second is almost due, the NTP protocol says a server must indicate this to its clients by setting the “Leap Indicator” (LI) field in its response. [..] Rather than doing this, we applied a patch to our internal NTP servers to not set LI, and tell a small “lie” about the time, modulating this “lie” over a time window w before midnight
In the video he does run on tiled stones even and over a small gap, see 0:39 to 0:49. It looks like he's not struggling but it's such a closeup that you cannot see if he lost balance or not afterwards. I'm still very skeptical though, that gap would be quite hard to cross on a skateboard without a small jump and on a skateboard your center of gravity is almost 2 feet further back than on this thing. Maybe the propulsion in the wheels help.
For visualizing a large quantity of crons, I'd recommend something akin to https://github.com/federatedmedia/cronviz which will graphically show when jobs are scheduled to run.
I built an ETL that uses a Go stream for the transform. Once the data has been processed it's written to disk on our analytics servers. Since it can keep up with the stream, memory footprint is very small (which also means we never have to hit disk on ETL servers).
Go outperformed our previous solution by over 60x, making our new bottleneck disk I/O instead of CPU.
PHP. It was what I used initially so I could have access to our internal libs since our main application is in PHP. After crashing the ETL server a couple times though, I decided to try moving the heavy lifting to Go.
When we benchmarked them, what would take PHP 30 minutes, Go could do in less than 30 seconds. Only the transform is written in Go, the rest of the ETL is still in PHP.
Yes, running in background and checking the status of the pid is coming to mind when one has to do that Bash. I always feel that it's stretching beyond the normal level of usage. For example what can you do with the output? There is no way to sync it unless you'll capture it in a file and analyze later. In cases when I need to write something parallelized I feel that using Bash isn't the best idea.
Yeah, I agree, but there are some use cases for a simple bash script. I updated the GIT repo with a PHP version that has output and errors like you said.
I don't necessarily agree with the OP but here's how I see it. Yes, releasing this information would be harmful to both the company and the customers. But the principle is: "there is no safety net". And in the long run it will incentivize building higher quality products.
e.g. When I golf, I refuse to take mulligans because it keeps me in a state of mind of, "this is my only chance". Whenever I break this rule, the rest of the day my golfing is worse.
