• P (unregistered)

    But did the code wrote by Nancy give the correct result like the original code?

    Leaving the answer to this dangling is TRWTF.

  • (nodebb)

    Except PHP counts seconds from the epoch, not milliseconds.

    It does have a DateTime class that can record microseconds, but that's not being used here. There are also the microtime function, but that oddly enough returns microseconds, not milliseconds, and the high-resolution timer, but that has nanosecond resolution.

    So where this program is getting its millisecond-resolution timestamps from, it's not directly from PHP.

  • trala (unregistered) in reply to Watson

    @Watson Milliseconds probably come from JavaScript...

  • The Dave G (unregistered)

    And that's not even the worst part. Anyone notice the for day loop and that the SQL resides in it? In other words: get Monday, append to results. Wash, rinse, repeat.

  • RLB (unregistered)

    So much bad. So much v4.0 bad.

    array() instead of []. array_push() instead of $result[] =. What are the other $results good for? Variables called $mysomething - what are we, a Windows 95 desktop? get_row(), apparently, is WordPress rather than a superfluous home-brew; fair enough. And what's with the cockamamie indentation in the SQL statement?

    So much bad...

  • tbo (unregistered) in reply to RLB

    You're arguing style, here. That's arguably worse than arguing semantics. There's nothing wrong with array(), and there's nothing wrong with array_push(). Hell, I have a customer still running 5.3, so [] is out of the question.

  • tbo (unregistered) in reply to Watson

    Every time they run an article on PHP it kind of reinforces the idea that there's no one on staff who's ever used it, because they never seem to know what they're talking about.

    Remy: I never do more research about a topic than when we run a PHP article, because, no, I don't actually know PHP, and PHP's fractal badness always has new dimensions to understand. In this case, I just went by what the submitter said, so yeah, this is probably a case where they were getting timestamps from JS, but that wasn't clear from the submission.

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    Why is that SELECT statement scattered across the page... oh right, fucking 4-space hard tabs mixed with blanks. Because the hard tabs would never ever show as anything but 4 spaces wide! (Can you tell what side of that holy war I'm on?)

    It's amazing how little WTF perpetrators seem to understand about basic math much less algebra. Maybe if they knew some real math we wouldn't see so much string math. String math is like using scissors (with rounded tips of course) and paste to do math, with a bonus that they can eat the paste too!

    But TRNWTF is that they actually used YYYY-MM-DD dates. Two steps back, but one step forward! PROGRESS!

  • onitake (unregistered)

    And the worst part isn't even that, it's that the author of the original code didn't even understand how prepared statements and parameter binding work. But hey, it looks like they were using an additional layer on top of PDO or the respective database driver. Maybe they did something smart in there?

  • sizer99 (google)

    Whenever you see code that looks like a square peg that someone who didn't understand has hammered into a round hole, you shouldn't think tutorial, you should assume that some outsourcer copypasta-ed from a random page on Stack Exchange.

  • (nodebb) in reply to I dunno LOL ¯\(°_o)/¯

    The YYYY-MM-DD requirement would have been forced on them by MySQL, because you just know they're using MySQL (and that might even explain the "$mydb" wart), and they at least had the good grace to use a datetime field.

    What's the betting that $day==86400000?

  • RLB (unregistered) in reply to tbo

    One, style very much is important, in a large enough code base. One array() may not be a disaster, but when you have myriads of lines of code all written in a mix of the style of 2012 and that of 2005, trust me, it gets a bother to read very quickly. Unless everything else is completely regular - which, in this case, it clearly isn't.

    As for still using PHP 5.3 when 7.3 is already out and 5.6 has already been end-of-lifed, that's bad enough; but using that as an excuse for anything rather than as a reason to say "sorry", that's just fooling yourself.

  • RLB (unregistered) in reply to onitake

    The extra layer is WordPress. Which has many bad things, but at least it provides basic database handling which is slightly more convenient than bare PDO. (Not that it's needed here, but that's another matter - at least it doesn't hurt.)

  • tbo (unregistered) in reply to RLB

    So what makes [] inherently better than array()? The fact that it was copied from javascript?

  • Christopher Allen-Poole (unregistered) in reply to trala

    Wow. So the ECMAScript languages (such as JavaScript and ActionScript) all store timestamps in milliseconds. Almost everywhere else stores them as seconds. In neither PHP, nor JavaScript, nor SQL are these datetimes though. A datetime in SQL is in the format yyyy-mm-dd hh:ii:ss. In PHP, it is represented by the DateTime class and in ECMAScript languages have a Date class. None of these represents a datetime as an integer, float, or any other number.

  • (nodebb)

    Well at least the guy managed to perform aggregation in his query. I once had to deal with an agonisingly slow end of month accounting routine which worked by selecting all the relevant records and summing the desired columns manually in a loop...

  • Ashley Sheridan (unregistered)

    MySQL lets you use strings instead of timestamps and it will convert them internally following fairly standard format rules (so best if it's an ISO-formatted date string).

    Would remove the need for all of this.

  • Some Ed (unregistered) in reply to urkerab

    Somehow, I don't think you mean manually here.

    Otherwise, you'd be talking about something like the situation I fixed right before getting my first real IT job. They had a program that would make a database query and generate a series of Excel spreadsheets. They sent each spreadsheet to a different secretary, to have them add up all of the numbers. A manager would then add the numbers each of the secretaries got together.

    My fix was to just have the SQL query return a SUM rather than the individual results. It still generated a spreadsheet, because that's what they wanted. I suggested they could send it directly to the manager, but at least the one day I saw they used it, they still sent the spreadsheet off to one of those secretaries.

    (For what it's worth, this didn't put anyone out of a job; they just had the secretaries do that job one day a month. They also had a backlog of secretarial work, due to, well, stupid crap like this.)

Leave a comment on “Seven First Dates”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article