• Darkenon (unregistered)

    TRWTF is not using colons, I'm sure most languages would let you use something like U+02D0, and think of all the fun you would have typing that everytime you need to call the method!

  • (nodebb)

    Arguably, TRWTF is not expressing the functionality in terms of the reasons for each format: reportFriendlyDateFromExchangeFormatDate or similar. Who (in the source code) cares what the detailed formatting is for report-friendly and exchange-format dates?

    Addendum 2020-04-09 07:06: To say nothing of it being better to store actual Date or DateTime objects and convert from them to strings as needed.

  • (nodebb)

    The first method claims to convert from HH:MM to HH:MM:SS. I'm dying to find out how they determine the seconds, if they're missing from the input.

  • Code Refactorer (unregistered)

    All these abbreviations... What does "d" stand for? Dot? Arbitrary delimiter? And "sp"? Whitespace? And MM? month or minute? Or sometimes the first and sometimes the second? So why not be consistent and also abbreviate colon with "c" and minus with "m"? (irony) Or use Microsoft's LPTCSTR? (Just joking). And how can you convert "hours:minutes" to "hours:minutes:seconds" if you do not know the seconds?

    Naming is difficult, so do not try to give a meaningful name like "addZeroSeconds" or "convertLocalToIsoDateFormat", because It could be not significant enough. (irony)

  • Anon E. Mouse (unregistered) in reply to Mr. TA

    7

  • SG (unregistered) in reply to Mr. TA

    The usual approach would be to default the seconds to 00 - and indeed, pretty good odds that the implementation of that method is just value + ":00"... though probably heavily obfuscated by some half-assed attempt to verify that the input value is in the correct format.

  • WTFGuy (unregistered) in reply to Steve_The_Cynic

    @Steve_The_Cynic: I agree w both your post & your addendum. As to the addendum ...

    We're stuck now with the reality that THE major system boundary in almost every app stack is pure human-readable text travelling over http. Which guarantees that stuff naturally leaves one layer as text and naturally arrives in the other layer as text. And in a lot of cases the dev in question only controls one side of that communication. As app stacks get fashionably cloudier and 3rd-party-provider-er there's often multiple layers of http involved. With multiple layers of (de-)serialization involving raw text.

    Back at the beginning, http served static text files to static text file renderers. If we'd had the foresight to realize that programability on both server and client was inevitably coming, and so program-to-program transmission was going to be the lion's share of the bytes in just a few years. we might have had a chance to develop a standardized binary object vocabulary and protocol. Oops.

    Of course every attempt to bolt one on later, e.g. SOAP, suffered from the "so many standards to choose from" and "that's too heavy for our quickie feature right here right now" problems. Plus of course interoperability across vendors.

    Having our lowest-common-denominator devs dealing directly with the lowest-common-denominator inter-system interchange protocol sure hasn't helped.

    That's another v1.5 oversight/miscue that will plague us for centuries.

  • Cysio (unregistered) in reply to Mr. TA

    Possibly zero them out

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered) in reply to Code Refactorer

    They are standard date format specifiers, e.g. from Java's SimpleDateFormat. 'd' is day in month vs. 'D' is day in year, while 'm' is minute in hour vs. 'M' is month in year. 'sp' is almost certainly space.

  • Q (unregistered)

    Arbitrary date and time values are rather meaningless until you specify a location. I suggest the following function to alleviate the problem:

    convertDDdMMdYYYspHHcolonMMtoYYYminusMMminusDDspHHcolonMMcolonSSat51deg28min40sNorth0deg0min5secWest(value);

  • Dlareg (unregistered) in reply to Anon E. Mouse

    As determined by a fair dice roll?

  • ooOOooGa (unregistered) in reply to WTFGuy

    If I was getting a datetime value as a string over a network connection (or from the database), I would immediately parse that into a DateTime object, pass that around to everything that needs it, and still only format it back to a string value right before displaying it.

  • Your Mammas name (unregistered)

    Bitching about variable names is a pretty weak WTF, especially ones that look like the result of outsourcing the code to companies with English as a second language.

  • MiserableOldGit (unregistered)

    I'd say this is someone trying to parse (suspected) dates out of freeform text, or other inbound crappy data you have no control over. Much as you shouldn't craft your own date functions (assuming your language has working ones), you do need to start then with ugly string mangling and/or regexing before you can start throwing what you've found and at fussy date functions.

    From that point of view these function names fall into the category "what the hell else do you call them?". Mind you, the combination of them suggests it's someone who doesn't really know what they are doing, as in that case you'd "normally" just have functions to turn scruffy data into date/time objects from whatever input .... and maybe one "from" function if you need to feed out some awful weird format. And having had to do this a lot, I've never come up with weird function names like that!

  • sizer99 (google) in reply to Your Mammas name

    Bitching about terrible method names is perfectly valid. They lead to bad, hard to maintain code because you can't tell WTF is going on just from reading it.

    And outsourcing code is possibly the biggest WTF of all. Yes, it's supposed to save money - but at the expense of time, sanity, and ending up with a giant chunky bowl of fecal stew. Some companies finally caught on that they weren't actually saving money in the long run.

  • Anon (unregistered) in reply to Your Mammas name

    The WTF is not function names, TRWTF is that by specifying the format at method name defeats the purpose of creating custom date methods.

    We would be bitching about method name if the method name was like formatDateAsMyMomLike.

  • Decius (unregistered)

    Proper notation would be GetHHcolonMMcolonSSfromHHcolonMM(value);

  • (nodebb) in reply to sizer99

    Yeah why not draw skyscraper plans and run construction sites with this quality of English language and technical terminology? "Long metal stick" for "I-beam", "gray stuff" for concrete, and "blue machine" for cranes. Things will go just fine! Just remember to hire Kerblekistan contractors for the job.

  • P. Wolff (unregistered)

    I did write my own date methods. And I'm not ashamed of it.

    Some of them before there were readily available libraries.

    Some of them when the libraries were unusable or gave results that were simply wrong.

    Well, bad is still better than not at all or plain wrong.

  • PlanB (unregistered) in reply to Code Refactorer

    d in this context ofcourse stands for "divider" being slash so the method convertDDdMMdYYYtoYYYYminusMMminusDD(value) does: 13/04/2020 to 2020-04-13 (with a missing Y for the "from" year)

  • David Mårtensson (unregistered) in reply to Mr. TA

    Easy, just append ":00"

    Its just to get a certain date format ;)

    Its still bad code and even more unreadable than usually but I guess many old systems skipped storing seconds to save space :P

  • gnasher729 (unregistered)

    Strings must only be used for formatting. You need functions that convert strings (coming from the user, or from a database that can only handle strings) to dates, and you need functions that convert dates to strings (that are displayed to the user, or stored in a database that can only handle strings).

    There is never any good reason to convert a string containing a date formatted in some way to a string formatted in some different way.

  • Some Ed (unregistered) in reply to sizer99

    The problem is that it's not companies that learn lessons, but people. People tend to come and go. So even though I work for a "company" that had "learned" this lesson, it still tends to happen from time to time.

    To many people, outsourcing programming is just like anything else. And, to a large extent, this is true. But the problem with outsourcing anything else is that the quality of the labor you get out of it is proportional to a random number that tends to average around the amount of common understanding of the field plus the amount of understanding of the field possessed by the person one has minding them divided by the amount of tasks (including this one) that person has on their plate.

    I don't have the expertise necessary to put values into that equation, but it's my feeling that in most areas of computer programming, those variables are a small number, a small number, and a big number, respectively.

    Oh, and it's probably important to note that the person minding the outsourced development is not necessarily the person who was assigned that job. Ideally, yes, but that person only counts if they actually are given the respect and backing needed for what they say to matter. If their manager overrules their every decision, it's probably really their manager who is "minding" the outsourced development - but with even more competing responsibilities and less expertise to balance that.

Leave a comment on “The Date Wrapper”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article