• (disco)
    PaulaBean:
    This topic is now unlisted. It will no longer be displayed in any topic lists. The only way to access this topic is via direct link.

    Frist!

    <!-- Posted by SockBot 0.12.5 "Guileful Ginny" on Thu Oct 23 2014 01:37:33 GMT-0400 (EDT)-->
  • (disco) in reply to sockbot
    sockbot:
    Frist!
    What took so long?
  • (disco)

    Looks like today is one of those obligatory PHP-bashing days. Paging @Arantor

  • (disco)

    TRWTF: storing a date as string.

    Bonus WTF in the replacement code: it uses strtotime. Description of that function:

    The function expects to be given a string containing an English date format and will try to parse that format into a Unix timestamp
    

    If you wonder what "an English date format" means, there's this note:

    Note: 
    
    Dates in the m/d/y or d-m-y formats
    are disambiguated by looking at the separator between the various
    components: if the separator is a slash (/), then the
    American m/d/y is assumed; whereas if the separator is a
    dash (-) or a dot (.), then the
    European d-m-y format is assumed.
    

    So anybody can insert whatever date format they want inside the database and it might even work?!?

  • (disco)

    Function is _isSmsCodeExpired()

    Karol replaced most of the function with this: return ((strtotime($genDateStr) + $intervalSec) > time()) ;

    That's TRWTF: The function now returns a Discobool (true when not expired, false when expired).

  • (disco)

    yup strtotime IS the real wtf, not a very good function to trust when working in a multi locale environment. Always enforce ISO 8106, or just plain Y-m-d H:i:s

  • (disco) in reply to sockbot

    I love seeing my anonymizer in action.....

    I wonder who wanted to post frist but didn't want to do it publically? (resisting urge to log in as sockbot and find out, successfully so far)

  • (disco) in reply to JBert

    No anyone can insert a unix date into the database, the application will take a date string and may or may not generate the result the user was expecting. This nasty UI problem though and always has been. There isn't really a "good" way to differentiate types of date entries other than to validate and reject dates like 30/05/14, but 10/11/14 how can you know? if you were expecting US format. You can try telling the user what to do but they won't read it. You can split the fields out but people don't like entering them separately, you can make them confirm the date after entry but that irritates them, etc.

  • (disco)

    Didn't realize the new format changed the tags... silly remmy comments.

  • (disco) in reply to JBert
    JBert:
    TRWTF: storing a date as string.

    TRWTF is storing dates/times in string format here. Like JBert said. No developer with a few months (or the common sense to use google/stackexchange) experience does this.

    Smarter solution would be to modify the system passing those strings to pass timestamps instead (Does mktime scare people?) so that you don't need to faff about with strtotime or worry about ISO/European/US formats.

    Edit: Even better, I just had to deal with this on Monday porting data from a legacy system. Fortunately I'm strictly dealing with European date format (And it was server side, not user input fortunately). Solution? Nearly identical. Oh, woe is me. Bonus points for months stored in string format (OCT, DEC, etc).

  • (disco) in reply to geoff

    That's when you use a format string / template.

    The blank template would look like.

    yyyy/mm/dd hh:mm:ss

    Then the user starts to type

    20yy/mm/dd hh:mm:ss

    Put the pattern right where they type and it doesn't obstruct.

  • (disco)

    Won't somebody please think of the llamas?

  • (disco)

    After thinking about it, I don't really get the whole increment thing anyway.

    So, you're going to check if the license expired... by adding 2 mins to the license-end date, and seeing if now is greater than that?

    Why 2 mins? In case you started the program seconds before it expired and it takes a while to get to this point?

    ???

    Not to mention this crap.

    intervalSec = 120 {(2 minutes)}.

    explode date into array.

    intervalMin = intervalSec / 60 {(2)}.

    intervalSec = intervalSec - (intervaleMin * 60) {(120 - 60*2, or 0)}

    seconds += 0; minutes += 2; seconds += 0;

    if (seconds > 60) ...

    Seriously? You didn't trust seconds?

  • (disco) in reply to xaade
    xaade:
    Seriously? You didn't trust seconds?

    Would you rather fight 60 second sized minutes, or 1 minute sized second?

  • (disco) in reply to thegoryone

    I have the pleasure of maintaining several sites where the developers thought it was a good idea to store date/time as a unix timestamp in a VARCHAR(255) (Its better for indexing?). Also they knew that the database couldn't be trusted to generate a unique primary key, so whenever they insert a new record, they make sure to set the id to a call to PHP's time() function (which has the added benefit of NOT WORKING when two records are inserted in the same second, how joyous!)

    And these apps were supposed to be written by people with 10+ years experience in web development.

  • (disco) in reply to NBeezy
    NBeezy:
    And these apps were supposed to be written by people with 10+ years experience in web development.

    I think we both know they weren't

  • (disco) in reply to thegoryone

    Actually, that's what they call "having 2 + 2 + 2 + 2 + 2 years experience".

  • (disco) in reply to aliceif
    aliceif:
    Looks like today is one of those obligatory PHP-bashing days. Paging @Arantor

    Nope, this isn't PHP idiocy, this is dev stupidity for not knowing that strtotime is even a thing.

  • (disco) in reply to thegoryone

    Yes, mktime (or even gmmktime) scares people. The number of people I have dealt with who don't understand WTF a timestamp is surely is TRWTF - but then again to their credit, they're not developers.

  • (disco) in reply to Arantor

    I know of one for definite that didn't as of a week ago. I.E. legacy system support I got roped into. I can't quite recall the conversation but the following happened.

    Other dev: What use is that? How would people know the date by looking at that? Me: You format it before you display it... Other dev: That's more work than storing it in readable format to begin with
    And this is the education sector. Is that irony? I can never remember the correct definition. Is *that* irony?
  • (disco) in reply to thegoryone

    I'm assuming said developer has never heard of the concept of separation of logic and presentation.

    As for it being ironic... it would only be ironic if he were educating people in IT. Right now it's merely another WTF in the room.

    As for the bonus irony... not unless the place you work at was supposed to have taught you what irony was in the first place.

  • (disco) in reply to thegoryone
    thegoryone:
    Is that irony?

    Was his shirt wrinkled? Collar unstarched? I fell like I'm not getting something here.

  • (disco) in reply to boomzilla

    On that note, what about tinny, zincy or maybe alumin[spoiler]i][/spoiler]umy?

  • (disco) in reply to Arantor
    Arantor:
    As for it being ironic... it would only be ironic if he were educating people in IT. Right now it's merely another WTF in the room.

    About that...

  • (disco) in reply to thegoryone
    thegoryone:
    About that...

    Yes?

  • (disco) in reply to boomzilla
    boomzilla:
    Was his shirt wrinkled? Collar unstarched? I fell like I'm not getting something here.

    That was an excellent Blakey impression, but I'm going to have to dock points for the lack of gratuituous profanity.

  • (disco) in reply to FrostCat

    FUCK YOU<o

  • (disco) in reply to boomzilla
    boomzilla:
    FUCK YOU

    I've still got that keyboard with the razor, you--oh, wait.

    Good one.

  • (disco)

    What you see:

    (code that gets date from DB)

    What I see:

    // this needs to be completely replaced

  • (disco)

    Well I think the whole mess could just have been done in the db (as thay already query the db for the expiredate the way I see it.

    So something along 'SELECT now() > date + INTERVAL '2 minutes' FROM table' (example if using postgresql) should do the trick..... That way they do not have to worry about date format or anything like that....

    Yazeran

    Plan: To go to Mars one day with a hammer.

  • (disco) in reply to Yazeran

    If it was a timestamp in the database, sure, that would be a thing.

    Would appear they were not that smart. Though I suspect for bonus points they were using a datetime column which would actually have let them do such things right at the SQL layer :laughing:

  • (disco) in reply to thegoryone

    If people engineered the way they code:

    On noes, the engine is still vibrating too much. Quick add more parts until it doesn't.

  • (disco) in reply to xaade

    Oh noes, the engine is still vibrating too much, and now excess parts are flying everywhere.

  • (disco) in reply to CoyneTheDup
    CoyneTheDup:
    Oh noes, the engine is still vibrating too much, and now excess parts are flying everywhere.

    Now you know which ones weren't necessary!

  • (disco) in reply to chubertdev

    I know, to make sure we account for every configuration of the engine,

    the engine should come with a factory to build engines, and then a factory factory, in case the specifications change so we can dynamically construct factories.

    Then.... I'll never have to work again.

    pffft... maintenance.

  • (disco) in reply to xaade
    xaade:
    On noes, the engine is still vibrating too much.Quick add more parts until it doesn't.

    The Kerbal Space Program thread is that way :arrow_backward: :arrow_double_down: :arrow_right_hook: :arrows_counterclockwise:

  • (disco) in reply to xaade
    xaade:
    If people engineered the way they code:

    On noes, the engine is still vibrating too much.Quick add more parts until it doesn't.

    Sorry to rain on your parade, but if you compare a modern engine with its double overhead camshafts, balance shafts, torsion dampers, active engine mounts, flexible exhaust downpipe, and bellows in the air intake, to a simple pushrod design with rigid exhaust and bolt-on inlet manifold, you will see that "Add more parts until it doesn't" is exactly what has happened.

  • (disco)

    I love how it handles extra seconds (well between 60 and 119) then shuffles back the minutes, hours, days, months and years if they overflow except for the last (add year) overflow that has forgotten to subtract 12 from the months. And also if the month overflows $daysInMonth will probably break. I am not au-fait with PHP but maybe someone can comment. But it looks like 2014-10-01 10:55:77 would be handled but 2014-20-01 10:55:20 would crash?

  • (disco) in reply to boomzilla
    boomzilla:
    Was his shirt wrinkled? Collar unstarched? I fell like I'm not getting something here.

    Did it hurt?

  • (disco)

    Here's the big surprise, he's actually using strtotime already.

    $daysInMonth = date("t", strtotime($expireDateArr['year'] . "-" . $expireDateArr['month'] . "-01"));
    
  • (disco)

    Adding seconds without taking care of any DST? Because I didn't see any mention of using UTC in there.

  • (disco) in reply to JBert
    JBert:
    TRWTF: storing a date as string.
    No claim being made here that it is. No indication what DBMS is being used here, but PHP's db client libraries all communicate with the DBMS by sending strings representing SQL queries and when dates come back they're represented by strings formatted according to the db's configuration; the client libraries don't convert those strings into any sort of date object.
  • (disco) in reply to TheIrritainer
    TheIrritainer:
    yup strtotime IS the real wtf, not a very good function to trust when working in a multi locale environment. Always enforce ISO 8106, or just plain Y-m-d H:i:s

    Having a serious ISO fetish I was also deeply offended by the formats the function uses, but it was the only function I found being able to add time interval of P1M. It had to be expressed as +1M, but at least it was correctly one month.

  • (disco) in reply to thegoryone
    thegoryone:
    TRWTF is storing dates/times in string format here.

    Unless you are using SQLite where it seems to be the recommended practice as that thing does not have any real types, only integer, real, string and blob (and is manifest-typed).

  • (disco) in reply to thegoryone

    He educates people in IT.

  • (disco) in reply to Watson
    Watson:
    No claim being made here that it is. No indication what DBMS is being used here, but PHP's db client libraries all communicate with the DBMS by sending strings representing SQL queries and when dates come back they're represented by strings formatted according to the db's configuration; the client libraries don't convert those strings into any sort of date object.

    I'm assuming this is MySQL, which has a datetime type - which is accessed as a string and returned as a string even if it is not really a proper string.

  • (disco) in reply to Arantor

    If it uses PDO, wouldn't you be able to call fetchObject or would the MySQL driver really force this to a string field?

    Disclaimer: I don't use PHP very often.

  • (disco) in reply to JBert
    JBert:
    If it uses PDO, wouldn't you be able to call [`fetchObject`](http://php.net/manual/en/pdostatement.fetchobject.php) or would the MySQL driver really force this to a string field?

    Disclaimer: I don't use PHP very often.

    If you're getting a DateTime column, it's coming back as a string whatever happens.

    fetchObject returns the row as an object, which is basically in this case a standard class instance with each of the columns coming back as public properties in that class. It's basically syntactic sugar.

    Here's the thing... what should it come back with? PDO in particular means abstraction, but even if we were being specific to MySQL for a minute with specific bindings (e.g. MySQLi), the reality is that a datetime is going to come back as a string. Partly for historical use (since I don't remember MySQL ever returning a datetime as anything other than what amounts to a string) and partly because things like PHP's DateTime are more recent than PHP's support for MySQL.

    But whatever... what would a datetime column become? Having it as a string is reasonably malleable and means you can strtotime... (oh wait haha)

  • (disco) in reply to Arantor
    Arantor:
    what would a datetime column become?

    MSSQL stores datetimes as a numeric representing the number of days since the epoch (01-01-1900 IRC). This allows an unambiguous way of passing them around and converting them

  • (disco) in reply to Jaloopa

    Ah, MySQL's datetime is not epoch related, meaning you can store pre-epoch dates and times if so inclined. It's also good until Y10k.

    I'd argue that having a string delineating d/m/y h:m:s is as unambiguous as a timestamp. The only question then becomes timezones and that's up to you to figure out anwyay ;)

Leave a comment on “The Beginning of the Zend”

Log In or post as a guest

Replying to comment #:

« Return to Article