• Michael R (unregistered)

    Sacre bleu!

  • (nodebb)

    I don't understand the obsession of some people to give something non-existent or unknown a specific value. I get the biological component of not being able to grasp someones own non-existence, but people are really taking their self replication-indoctrinated fears to another level when coding. Or maybe it has nothing to do with biology, who knows at this point.

    Accept nulls and handle them accordingly, they are part of the universe. There's no point in trying to some sort of magic religious value in the sky and pretend they don't exist :-)

  • De Gaulle (unregistered)

    It was a very adequate choice. Whoever wrote this code should be made to experience the guillotine.

  • (nodebb)

    I wouldn't be surprised if the developer thought along the lines of, what value do i use as the token for "null"? Hmm, minimum date is not a bad idea. The minimum value is January 1, 0001, which is based on the birth of Christ. I'm French, we have a secular republic, and in the history of my great republic, there are a number of dates which are more important than when some Jew was born in Nazareth millennia ago. Bastille Day sounds perfect!

  • Staircase27 (unregistered)

    Given the names used I think this implies something worse than "loads of stringly typed operations", it looks to like building sql queries by string concatenating the values into the query which means very easy SQL injection attacks.

  • (nodebb) in reply to Mr. TA

    Minimum date is also super dangerous.

    Ever tried DateTime.MinValue.ToUniversalTime() ? You expect an exception in certain cases, but it actually just returns silently DateTime.MinValue - so when you convert it back to local time, it's half of the time wrong.

  • John Melville (unregistered)

    I don't think this is WTF. You needed a sentinel value. In some languages (like c#) nullable date is actually a few bytes bigger than a simple date, so picking a sentinel date makes sense and Bastille day is as good as any other. (The advantage of not having 0 as you sentinel is that when you see the sentinel you are pretty confident that it was an explicitly set sentinel value and not just uninitialized memory.

    Because I am a solo coder I often use my birthdate in tests and such. The date is absolutely indistinguishable from a million others to anyone but me. That way when I see it I know it came from my test cases.

  • (nodebb)

    TRWTF is that they're using types and values specific to Oracle, but (apparently) with a PostgreSQL driver.

  • (nodebb) in reply to MaxiTB

    so when you convert it back to local time

    It's a sentinel value that indicates "no date/time available", so if you convert it to local time, you become TRWTF. (This is the advantage of a nullable type, because your sentinel value becomes self-evidently not-convertible-to-local-time.)

  • (nodebb) in reply to Steve_The_Cynic

    Oh yeah, I totally agree. But keep in mind, whenever I saw this in the wild, it was because someone thought it's a smart way to no longer check for invalid values and just let it go through the business logic and hope for the best. Hence I consider using DateTime.MinValue at all an anti-pattern since .net2.0 where we got nullable value types.

  • Not French (unregistered)

    Everyone is complaining about using some arbitrary date as a sentinel value, but nobody points out the bonus WTF where said date is a hard coded string that gets converted into a DateTime object only to be converted back into a string with different format. Why not just write the sentinel value in the required format? A simple string must not have looked 'professional' enough :)

  • Peter D (unregistered)

    I once used 1752-09-11. I needed to write to a log table to track errors. The date field was NOT NULL, but I needed to track the error 'Date not given'. The date never existed, at least in what is now the USA.

  • gman003 (unregistered)

    At one of my first jobs, as an intern, the senior dev had a habit of using -666 as a failure value. Negative because most stuff is only positive, 666 because he was a giant metalhead.

    When the product was sold to its first client, a Catholic school, I did a grep through the codebase to replace them all with something else, so we wouldn't get angry calls when they showed up in a user-facing error message. I just made them -1 I think? These days I'd use null, or exceptions - well, actually, these days I'd have written it in Rust so it'd be Err. But back then I wasn't going to rearchitect everything.

  • Rob (unregistered)

    TRWTF is using a non-constant sentinel value, so it's harder to check that the result actually is (equal to) the sentinel value.

  • Officer Johnny Holzkopf (unregistered) in reply to Rob

    Eau contrair! Wouldn't it be even easier to use a date like "0000-00-00" if it's already stringly typed? And return it directly (because of "As String")? Any further attempt to convert this return value into a DateTime (or anything else) would fail, and proper exception handling would result in the desired "no date available" path...

  • AussieSusan (unregistered)

    This makes no sense to me - according to Wikipedia (and most of the rest of the world) the way the French represent dates is dd/mm/yy

  • (nodebb)

    I don't think this is WTF. You needed a sentinel value. In some languages (like c#) nullable date is actually a few bytes bigger than a simple date, so picking a sentinel date makes sense and Bastille day is as good as any other. (The advantage of not having 0 as you sentinel is that when you see the sentinel you are pretty confident that it was an explicitly set sentinel value and not just uninitialized memory.

    This is why we have functional-programming wrappers like Option<>. Make "no value" very explicit and hard to ignore, and yet easy to use in chained calculations.

  • Loren Pechtel (unregistered)

    I definitely see the merits of non-zero sentinel values. And such sentinels should be far enough from the realm in which the code is operating that they are obvious failures. Anyone French who knows computers will recognize this as a sentinel.

    @RandalSchwartz--explicit no-value options are good in the code, but this is the database.

    As for what this code is doing--I can see some sanity here: this ensures any parseable date is put in a standardized format. The programmer didn't want to reinvent the wheel. The only WTF is why it's returned as a string.

  • Jason Stringify (unregistered)

    TRWTF is of course the MM-dd-yyyy format.

  • (nodebb)

    I propose that, following historical precedent like { FALSE, TRUE, FILE_NOT_FOUND }, Bastille Day become the official Other Date for when the standard ones don't fit.

  • TechHound (unregistered) in reply to Jason Stringify

    TRWTF is of course the MM-dd-yyyy format.

    No, the real WTF is people who (still) can't grasp the notion that not everyone wants to do things the same way as them, that other methods can and do have merit. IMHO, it makes sense to establish the context of the month before the day of the month, as the latter isn't very useful without knowing the former. If you prefer date before month, then by all mean, use that. I personally perfer year, month, day myself (e.g., yyyy-mm-dd) but to each their own.

  • Graculus (unregistered)

    Perfect good coding for integration work where you can not be sure of valid ranges especially when using SQL. Worked on one project and we used the Battle Of Hastings. If I remember correctly it was a Saturday and we lost at home.

  • (nodebb) in reply to John Melville

    Perhaps you should use Bastille Day instead; that way you don't have to use a critical piece of PII :)

  • Craig (unregistered)

    TRWTF is using IIf instead of the If ternary operator in .NET code.

Leave a comment on “Historical Dates”

Log In or post as a guest

Replying to comment #687045:

Log Out

« Return to Article