GitHub search for 84600 seconds. Oops.
github.comHonestly, I think there's a little something to this submission beyond the "Ha ha, lots of people made typos that could cause big problems" factor.
A public repository like GitHub makes checks for common errors like this really easy. Would it be feasible for GitHub or the community to automatically recognize broad classes of these likely errors and notify the authors? How sophisticated could that sort of tool become?
Maybe "given enough bots, most bugs are shallow".
I agree, it's too bad they banned bots [0], one alternative I see is:
>> Yeah, maybe the answer is a hybrid, bots that look for common mistakes and a website that lets people login to github and displays the potential fixes so they can fix the code in the browser and send the pull request. Like a way to try and introduce people to open source through guided fixes more or less. [1]
Yes, in fact Amazon already does this. It will frequently warn you if your AWS keys are published in Github.
I wonder if Github will ever reconsider allowing bots [0]. There are bunch of things like this that would be cool to have pull-requests automatically generated for. Security fixes would be another place where I can see bots helping to fix common mistakes.
Yeah, I'd love to help in some way, but the number of results is huge and without bots I'm discouraged from doing anything manually.
Maybe we can create a resource of common typos in numerical constants that would auto-detect by edit distance? But I suppose most people willing to check a resource like that probably already double check their arithmetic. (That said, I've probably had this exact bug somewhere in my coding history, so no shame.)
Yeah, maybe the answer is a hybrid, bots that look for common mistakes and a website that lets people login to github and displays the potential fixes so they can fix the code in the browser and send the pull request. Like a way to try and introduce people to open source through guided fixes more or less.
86400 seconds is 24 hours. It is surprisingly commonly mis-entered as 84600 seconds, as evidenced by this search. As such, many unintended consequences can ensue.
Haha, should be 86400, not 84600.
I liked this one:
SECONDS_PER_23_5_HOURS = 84600That is a very common value to use when you want something to either occur a bit more than once a day, or time out in a bit less than a day.
And to keep the discussion interesting, also, 12 seconds is a pretty popular timespan to use when you want something longer than 10, but shorter than 15.
If there was an 84600 with no hinting variable names nearby, anyone reading would have trouble figuring out the author's intention. Any other number (say... 81234) would be unambiguous. In the words of Douglas Crockford, "All that you know about the code is that the programmer was incompetent."
I certainly have some code that adds 86399 to encompass the entirety of the day.
This is in languages I use with less robust date logic, of course.
Except it shouldn't, because when you have a leap second occur, suddenly you're off by a second.
A day is a day, it's not 86400 seconds.
Most operating systems and frameworks don't expose the concept of leap seconds to user code. For example, Unix time is the number of seconds since the epoch ignoring leap seconds, so a program that compares timestamps generated by time() would be correct in assuming that a day is 86400 units of time_t.
It's actually not that many places where it's wrong: Anything from page 57 to 100 is one repo that does it consistently wrong: https://github.com/sconklin/solardata, then there's quite a few places that are partial matches only (seconds, but not 84600), there's quite a few places where it's a least not obviously wrong (page 38, where it matches on "PHI( 1) +6.18900e+05-7.84600e+05i Hz") and a ton of places that get copied around (the first pages are all bundled versions of the sonata cache interface).
HN Challenge: name a scenario in which defining a constant as 86400 is better then defining it as (60 * 60 * 24).
Or, are there languages where you can't declare a constant with a multiplication expression?
> are there languages where you can't declare a constant with a multiplication expression?
obviously PHP.
php > const X = 1; php > echo X; 1 php > const Y = 1 * 2; Parse error: parse error, expecting `','' or `';'' in php shell code on line 1 php > echo Y; YFixed in the (upcoming) PHP 5.6.
To me it's a coding style thing. The argument for 86400 would be, too many operators makes things damn confusing. When your define expands in the preprocessor to a function sixteen operators long, you have made a mess.
I find myself with pre-optimization issues on my new code and define constants multiplied out rather than add that .000000001% extra overhead of doing the multiplication - it's a sickness.
Actually in all likeliness your compiler will do tgat for you anyway.
Disturbing enough that - despite having used 86400 a bazillion times (yes, literally) that it didn't look wrong at first glance.
Many of those are legitimately meant to be 23.5 hours, not 24 hours (TTL defaults, approximates for converting seconds to days, etc.)
I don't think it's right to judge someone just because they have 23.5 hour days. To each their own, I say.
Humorous as this is, it doesn't seem newsworthy. Maybe submit to The Daily WTF next time?
And none of them have any Stars: https://github.com/search?q=84600+seconds+stars%3A%3E0&type=...
I don't understand.
86,400 is the number of seconds in a day. This searches for the number of times a piece of code transposed the 6 and 4.
There will eventually be 84,600 replies to you telling you that there are 86,400 seconds in a day.
Probably the fact that there are 86400 seconds in one day and apparently lots of people typed 84600? Not really my sort of humor, but mmkay.
Number of seconds in a day = 60 * 60 * 24 == 86400, rather than 84600.
I actually don't understand either. Explain OP?
86400 seconds = 24 hours
84600 seconds = typo ;)
It's the number of seconds in a day.
There are 86400 seconds in a day
A day is 86,400 seconds.
Sometimes.
Even if you're using 86400, remember the possibility of leap seconds if you need absolute precision.
Time makes my brain hurt sometimes.
This should never be entered like that. Not only it's prone to typos, it also requires a comment to accompany it. Since just about every compiler/interpreter folds constants, one should write it as 60 * 60 * 24 which would run without a performance hit.
I first read this as 'Github search takes 84600 seconds'. Oops :)
A day is not always 24 hours.
But 24 hours is always 24 hours
I believe more in a day having 24 hours than I believe in daylight savings.
Easy mnemonic: 60 * 60 * 24 = 864e2 (scientific notation). Take down 2 each time, and shove an e.
Easier mnemonic: 60 * 60 * 24
The compiler is going to do the operation for you.
Of course. I use 864e2 to remember that it is 86400 when I do calculations on paper.
check out 48600 seconds for ruby, https://github.com/search?q=48600+seconds&type=Code&ref=sear...
Looks like it's all coming from use of the tzinfo gem. See: https://github.com/tzinfo/tzinfo/blob/61fdd4359117e9a406c546...
eh - and what is that supposed to show? That there's roughly 13.000 projects that vendored a version of activesupport containing a file that allows converting "48600" to a rational value?
I think that's timezone offset
`60 * 60 * 24`