Even if you're using 86400, remember the possibility of leap seconds if you need absolute precision.
Time makes my brain hurt sometimes.
GitHub search for 84600 seconds. Oops.
51–60 of 64 posts
Re: GitHub search for 84600 seconds. Oops.
#52Re: GitHub search for 84600 seconds. Oops.
#53I 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. [0] http://www.wired.com/2012/12/github-bots/
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 cod…
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.
Re: GitHub search for 84600 seconds. Oops.
#54check 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...
Re: GitHub search for 84600 seconds. Oops.
#55Honestly, 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…
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]
Re: GitHub search for 84600 seconds. Oops.
#56check out 48600 seconds for ruby, https://github.com/search?q=48600+seconds&type=Code&ref=sear...
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?
Re: GitHub search for 84600 seconds. Oops.
#57Haha, should be 86400, not 84600.
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.
Re: GitHub search for 84600 seconds. Oops.
#58HN 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?
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.
Re: GitHub search for 84600 seconds. Oops.
#59Easy mnemonic: 60 * 60 * 24 = 864e2 (scientific notation). Take down 2 each time, and shove an e.
Re: GitHub search for 84600 seconds. Oops.
#60Easy 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.