• P (unregistered)

    And when pressed on the cow-orker who wrote this code and ask them why they didn't just use momentjs, they answer with "BuT mOmEnT.jS Is ToO BlOaT, wE dOn'T WaNt BlOaT iN OuR FrOnT-EnD cOdE"

  • (nodebb) in reply to P

    Assuming they've even heard of Moment.js. The number of "experienced" people who have never heard of or want to hear of third-party libraries rather than roll their own is often astounding to me.

  • mitch (unregistered)

    So the final \d needs to be in front of the optional group instead of behind it. While this is a (simple to find, easy to test for) bug, I wouldn't write a blog post about something like that ;-)

  • WTFGuy (unregistered)

    @DocMonster : It's a holdover from the days before widespread open source. Back then "3rd party libraries" meant buying a pig in a poke from a small company that often went out of business 2 years later leaving you in a jam. And which sometimes came with pretty restrictive licensing.

    So for maintainability and salabililty you either used the OM/API that came with your language or you rolled your own.

    Today we have the opposite challenge. Github, et al, have hundreds of libraries for every common business or logic domain. Which are reliable? Which are well-maintained? Other than folk knowledge, nobody knows.

    And nobody can predict which will still be being maintained 3 versions of your underlying environment hence. Witness all the WTFs arguing about the style of code written for v2.0 when v6.0 is now current. Doesn't matter if we're talking about Java, javascript, .Net, *nix, etc. Each is continuously mutating.

    It's bad enough we're stuck with our platforms being so plastic; deliberately adding a whole bunch of other asynchronous uncontrolled change to your effective codebase is not obviously sound engineering.

  • WTFGuy (unregistered)

    Seems to me the real problem here is Jim changed the API contract without telling the client.

    The field is named "record_update_date", and is configured to be validated as a date. So Jim's change now delivers a datetime instead of the date that used to be delivered. Or if the field wasn't part of the previous payload at all, Jim is guilty of really crappy naming.

    Yes, there's a dumb bug in the validator, as mitch points out. But that bug has been dormant for however long precisely because nobody else was dumb enough to pass a datetime configured to be validated as a "date".

  • Angela Anuszewski (google) in reply to WTFGuy

    Or you work for someone that still values "security through obscurity" and doesn't want you to use third party open source.

  • Foo AKA Fooo (unregistered) in reply to mitch

    Seeing as email envelope timestamps (not necessarily the Date header) put the time in the middle of the date ("Tue Aug 15 12:34:56 2019"), putting it in the middle of the day number seems to be the next logical step.

  • Jeff Chadwell (github) in reply to WTFGuy

    He didn't send a date-time, at least not according to the way the validation code is written. If the validation code was defined correctly, the zeroed-out timestamp he included in the date would be valid. He sent what should have been a valid date according to the API's contract.

    If the original author truly wanted just a date in that field, they shouldn't have allowed an optional zero timestamp in the date.

  • matt (unregistered)

    Undeviginti is 19, but remember, our month names are two off numerically. Your birthday is in Septemdecimber.

  • Parse This (unregistered)

    Something in the data getting passed by back his web service was fighting with the front end.

    ERROR: Linguistics unexpected. For additional details see log file

  • Anonymous (unregistered)

    When transmitting dates to another system, ISO8601 is the last thing you want to use. Every system that integrates with yours is going to have to have their own function to convert the ISO8601 date into a standard unix timestamp, either by pulling in a library or foolishly writing one themselves. Just cut out the middle man and send the unix timestamp directly! "But we need the timezone!!!" Then send it in a separate field instead of smashing multiple values into a single string.

  • medievalist (unregistered) in reply to Anonymous

    Always use ISO8601. Internally, externally, everywhere, for everything. I've used it on my legal documents and tax forms for decades and no, I am not kidding.

    Dijkstra said "The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise."

    Admittedly, unix epoch time is the second best choice, but don't settle for second best.

  • Anon (unregistered)

    TRWTF is assuming that there can only be one leap second per day.

  • Olivier (unregistered) in reply to Anonymous

    I don't see the problem with the time zone. Unix tmiestamp has no timezone, it is the same everywhere around the globe. Timezone us only a matter of local display.

  • Olivier (unregistered)

    As I like to remind, when using regex that are longer than 10 characters, The Regex Coach is your friend. It has been developed for Windows but works nicely in wine.

    Pop in your regex and throw a bunch of test cases and check that your regex give expected results.

    Or pop in some samples of the strings you want to match and slowly build your regex.

  • (nodebb)

    TRWTF is Date.parse()

  • (nodebb)

    Admittedly, unix epoch time is the second best choice, but don't settle for second best.

    It's a long way from second best, since it can't easily be converted to (or from) an accurate representation in any real-world time zone. From time to time, there's a minute with 61 seconds, and each time that happens, converting UNIX epoch to (or from) real time becomes a little harder.

  • J-L (unregistered)

    For testing regular expressions, I recently discovered "pcretest" on some Linux machines. Just fire it up, and give the following two lines of input:

    /s+/gi Success!

    And you'll see that it parses "S" and "ss" from the string "Success!". (Hit CTRL-D to exit.)

    "pcretest" is meant to accompany and help with "pcregrep", but it's a great way to toy around with regular expressions regardless.

  • markm (unregistered) in reply to Foo AKA Fooo

    A date-time formatted with the date in the middle like "Tue Aug 15 12:34:56 2019" probably comes from the 'c' standard library functions to turn an internal format into a string for display, such as asctime() and ctime(). And the standard library doesn't include any function to reverse this into an internal format. I once had to write a function to take the data dumped into a text file by an ancient program, identify the date-time, and reformat it into separate date and time strings. That only requires moving substrings, so once I've validated that it is in that format, the reformatting is fairly easy - but it might include "Aug 1" instead of "Aug 01", etc., so some branching is needed. Reformatting to the "2019-07-29T00:00:00.000" format is nearly as easy. Not using the functions that produce that mixed-together format in the first place would be easiest, but I didn't control that code.

    I don't fully understand regex, but I do know this: It's good at checking for the correct characters in each position, such as ensuring the month is two digits, (0-1) and (0-9). But that is only the preliminary filter before you take the two digits together as a number and range check that number is 1 to 12. It needs a check after the regex like:

    if(valid) { strncpy(monthString,data+5,2); /* Copy the month. For those unfamiliar with c, "data+5" gives a pointer to the 6th character. This is safe because the regex ensured the month is in the usual place and includes two digits. */ sscanf(monthString,"%d",&monthNum);
    if(monthNum < 1 || monthNum > 12) valid = false; }

    Similar code is needed to check the date, and maybe the year if you can define the expected range.

Leave a comment on “A Devil With a Date”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article