Geek o'clock



  • Several years ago, I was responsible for part of a process that generated flattened database exports in the form of Excel spreadsheets to be used in a Word mail merge. Basically, the data source to fill in form letters like this:

    Dear [CustomerName],

    This is the [NotificationOrdinal] time we've written you about your outstanding balance of [OutstandingBalance]. If you do not pay in full by [RepoDate], we will regretfully have to blah blah blah.

    One day, my manager calls me over to help with an issue one of our sales staff was having. In this case, [RepoDate] was evaluating to:

    1900-01-01 00:00:00

    "There's probably no date entered for that record," I offered.

    "I see that. But what the hell is this, geek o'clock? Can't we have the normal-people date here instead?"

    "Oh, heh. Can't they change the date display format in Excel before performing the mail merge? The time1 will be useful for some of these columns, and having conditional per-column formatting rules on export are going to greatly complicate the process2."

    "That means that they have to manually edit this spreadsheet every time. Why don't you just make it MM-DD-YYYY like the rest of the world uses? Nobody cares about geek time."

    I saw some substantial problems with this. "What about our overseas clients? Not everyone uses month-day-year formatting."

    "Then they can format their dates American-style."




    1. This system was written in the days of SQL Server 2000, so a sudden jump to date and time was not on the menu.

    2. In order to simplify his code, the developer in charge of the other side of this process (who had more clout than I) INSISTED THAT THE COLUMN HEADERS BE RETURNED AS THE FIRST ROW OF THE RESULT SET. That's right, every column returned had to be converted to VARCHAR. DataTable.Columns? Never heard of it. So while his export code was about ten pretty lines of C#, the stored procedure that did the heavy lifting was well over a thousand lines. Why so large? He wanted a single procedure to call that would bend to whatever parameter combination he felt like passing on any given day.



  • @Groaner said:

    I saw some substantial problems with this. "What about our overseas clients? Not everyone uses month-day-year formatting."

    Should've been said "No-one else in the world uses month-day-year formatting"

    "Geek Time" (YYYY-MM-DD) is also the standard date layout in East Asian countries.

    Even were that not the case, your manager's an ass.



  • @Groaner said:

    "Then they can format their dates American-style."

    As an Australian who has had to send many defect reports back to our US partner because things get broken when used in a DMY (or, yes, YMD) date format, I offer you my cluebat (more a +10 wreckingball of clue-giving) for use on your old manager.



  • @trithne said:

    Should've been said "No-one else in the world uses month-day-year formatting"

    About 90% of our clients were in the US at that time.

    Amusingly, around this same point in time, this same manager was trying to branch out to European/Asian prospects, and telling them, "Oh sure, our system can handle your culture, no problems at all!"

    @trithne said:

    "Geek Time" (YYYY-MM-DD) is also the standard date layout in East Asian countries.

    This is my preference as it's the least ambiguous and sorts asciibetically.

    @Spencer said:

    I offer you my cluebat (more a +10 wreckingball of clue-giving) for use on your old manager.

    One of those would have been mighty useful on this and many other occasions.



  • @Spencer said:

    a +10 wreckingball of clue-giving

    🙂





  • But yeah, definitely bad code smells here.

    Not having the proper data types for the DataColumns in the DataTable? You're Doing It Wrong™.

    Monolithic SP to handle every possible combination instead of having strict rules to enforce business logic? You're Doing It Wrong™.



  • The rules were so strict that the moment Big Important Client A or incompetent-but-politically-powerful coworker complained about something, they would change. Naturally, yours truly would get all of the complaints and none of the glory.

    There was no winning.



  • It forces you to give them a simple choice. Let you use your experience and knowledge, or find someone to replace you.



  • @Spencer said:

    As an Australian who has had to send many defect reports back to our US partner because things get broken when used in a DMY (or, yes, YMD) date format, I offer you my cluebat (more a +10 wreckingball of clue-giving) for use on your old manager.

    We're going to have the opposite problem when we expand into the US. Other programmers are actively removing YMD in favour of DMY. Going to be fun to find all the hard coded places to make a configurable option for MDY.


  • Discourse touched me in a no-no place

    Use a three-letter month abbreviation and four digits for the year. Like that, people very quickly figure out what the date is unambiguously, whatever the order is. (You shouldn't be sorting on the rendered version anyway, in case that matters.)



  • Yeah, let's see that for Spanish:

    • Jan != Ene
    • Apr != Abr
    • Aug != Ago
    • Dec != Dic

    No, that doesn't work.



  • @Groaner said:

    "Then they can format their dates American-style."

    'Murica


  • I survived the hour long Uno hand





  • @Groaner said:

    This is my preference as it's the least ambiguous and sorts asciibetically.

    Extensible, too!



  • @chubertdev said:

    http://i.imgur.com/R3LZZkK.gif

    This is wonderful. Where's it from?



  • @Eldelshell said:

    Yeah, let's see that for Spanish:

    • Jan != Ene
    • Apr != Abr
    • Aug != Ago
    • Dec != Dic

    No, that doesn't work.

    It's not the same, but a Spanish speaker isn't going to see 11-Jan-2014 and think "Wow that must mean November Jan'th."



  • I'll run a poll in a pool.



  • It's from a commercial, I can't remember what for.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.