• Debra (unregistered)

    Am I weird if I immediately thought about doing modulo and division to unpack that date format, instead of converting it to a base-10 string and substringing the relevant parts?

  • 516052 (unregistered)

    You probably are. Your solution sounds like just the sort of "clever" idea that works in the long run but is going to hurt the brain of people coming after you to clean this mess up.

  • van Dartel (unregistered)

    Usually I go autopilot when reading a codesod: after a bit of mental refactoring I'd see how the codesod can easily disappear while still fitting within a nice or at least defensible architecture. This is the first codesod I've seen where the code doesn't seem to mess up the architecture as much as that the architecture messes up the code (either that, or the there was a coup d'état by coders and the architects were disposed of).

    If indeed the code jives with the requirements, the code is a requiem to the requirements.

  • Roeleboel (unregistered)

    quote: store the date as 20201012: Octobel 10th, 2020

    This raises questions:

    • Which calender system has an Octobel-month?
    • How is 20201012 parseable to Octobel 10th? Do your days start counting at -1? Octobel 12th I would understand, but 10th?
  • (nodebb) 
    sSql += " ) where 1=1";

    Is this some sort of pre-emptive SQL injection strike?

  • Dennis (unregistered)

    Errr... That format is still the best date-only format. Okay, maybe just under yyyy-mm-dd, for being formally standardised under ISO.

  • eyescream (unregistered)

    "Octobel" :)

  • Virginia N (unregistered)

    This is the explanation for the subquery, and for the where 1=1

     if (SFourn.Length > 0)
        {
            sSql += " AND FOUR ";
            switch (iOperateur)
            {
                case 0:
                    sSql += " >= 'STRINGTOREPLACE'";
                    break;

                case 1:
                    sSql += " LIKE 'STRINGTOREPLACE%'";
                    break;

                case 2:
                    sSql += " LIKE '%STRINGTOREPLACE%'";
                    break;
                case 3:
                    sSql += " = 'STRINGTOREPLACE'";
                    break;
            }

            sSql = sSql.Replace("STRINGTOREPLACE", SFourn);
            if (sColTri == null || sColTri.Length == 0) sSql += " ORDER BY FOUR";
        }
  • van Dartel (unregistered) in reply to Debra

    Not weird at all. I disagree with 516052: anything that works in the long run is fantastic (even it is deemed "clever", which often is an euphemism for "I don't get it").

    Just don't do it in-line (certainly not without comments). Instead, create a function that does the unpacking using div & mod (I'd recommend comments for educational purposes).

    If I have any objection to your suggestion it is related to priority: the way dates are unpacked is not the biggest WTF here.

  • Ruts (unregistered) in reply to Dennis

    Agreed, for a human-readable, cross-platform, mostly-international approach, eight digit dates can work very well. Using the hyphenated form you have shown can also help avoid the American juxtaposition of day and month, which they do at the start of date strings but not at the end.

  • Brian (unregistered) in reply to Debra

    Nope, not weird at all. I used to work a lot with this kind of date encoding, and doing basic math rather than a bunch of type conversions and string slicing was the standard way of unpacking it.

    Very simple: var year = date / 10000; var month = (date / 100) % 100; var day = date % 100;

  • var commentdate = service.call(UNPACK_DATE, 20201012) (unregistered)

    Am I weird if I immediately thought about doing modulo and division to unpack that date format

    No, that would be the normal way to do it, surely.

    The date unpacking is a pretty minor thing, though - yes, using string slicing (badly, though the optimiser might cut the multiple ToString calls) to do that is dumb, but it is functionally correct and there's no way that's the main performance issue in a method that goes to the database and maybe to a web service.

    The GetMC definition and the call have different arguments - anonymisation failure? Hard to come to an opinion about the web service thing given that.

  • (nodebb)

    A "clever" former cow-orker of mine figured out how to "safely" (ha ha) reduce that date-string (or number; your choice) to 5 characters.

    First, of course you use only 2 chars for the year, because it won't be 2100 until after we all retire.
    Second, and most devilish, assign the third character a hex-ish value for the month.
    Examples: 2020/March/15 becomes 20315 . 2017/November/4 becomes 17b04

    WCPGW?

  • (nodebb) in reply to Roeleboel

    "quote: store the date as 20201012: Octobel 10th, 2020 This raises questions:"

    Not the least one of those questions is: why was "Octobel" fixed in the story, but is 20201012 apparently still October 10th, 2020?

  • Yazeran (unregistered) in reply to cellocgw

    now that 5-digit date format is just evil. unless you have the definition you have zero chance of figuring out that the values are dates...

  • (nodebb) in reply to cellocgw

    First, of course you use only 2 chars for the year, because it won't be 2100 until after we all retire.

    It's a good thing, I guess, that we don't ever need to store information about things that happened before 2000. Nobody's older than that, right? I mean, like, even dinosaurs aren't that old.

  • Foo AKA Fooo (unregistered) in reply to cellocgw

    Why not go all the way then? Since there are only 36525 days in this century, you can easily store them in 2 bytes or 3 printable ASCII characters.

  • Foo AKA Fooo (unregistered) in reply to Dennis

    For textual representation, yes. But for storage, a binary format is often preferable, just like we usually store integers in binary, not as strings.

  • Steve (unregistered)

    Ok, I don't know anything about C#, but is it really true that you can declare a variable inside a block and have it visible outside the block? That is, is this really not a no-op?:

    if (oDataReader["DEB"] != DBNull.Value)
{
    DateTime dt = DateTime.Today;
    dt = UnpackDateC(dt, Convert.ToInt64(oDataReader["DEB"]));
}
  • (nodebb) in reply to Steve_The_Cynic

    The off-the-shelf package that used to be the bulk of my work dealt with Y2K in stages:

    1. IIRC there was a stage where years were still 2 digits, but assumed to fall within 1930-2029 (with an option to adjust that window)
    2. Then they converted them to 2 characters using base-64 math (ASCII values 32-95 representing "digits" 0-63), which covered any year from 1626 through 4095 without any ambiguity of "has this year already been converted"
    3. Then they converted to YYYYMMDD as part of a more extensive revamp (first module was released around the time of Windows Vista, most of them have gone through this level of revamping by now, though a few of my clients are still using #2 era versions due to custom programming or just not bothering to upgrade anything that isn't literally broken)
  • (nodebb)

    Jibes with requirements.

  • Matthew (unregistered)

    TBH, an interface my companies product interacts with uses a similar format nowadays too, except it also includes time. So today would be 20201013093900, which is... somewhat annoying to read. The joys of legacy interfaces...

  • MiserableOldGit (unregistered) in reply to cellocgw
    A "clever" former cow-orker of mine figured out how to "safely" (ha ha) reduce that date-string (or number; your choice) to 5 characters.

    Teach him base64 encoding, what harm can come of it?

  • MiserableOldGit (unregistered) in reply to supermagle
    sSql += " ) where 1=1"; Is this some sort of pre-emptive SQL injection strike?

    Well it might thwart a straightforward attempt, but at best it could only be called obfuscation.

    I think it's really so that SQL block can be followed by a bunch of if statements that append " and [something]=[somethingelse]" without needing to work out if the where keyword was there, the "1=1" just means the statement is valid even if no conditionals get added.

    Not the worst crime here, but it's a symptom of a scruffy way of building a SQL statement.

  • (nodebb)

    OK I think there's some confusion in the comments with 8 digit date formats, specifically Dennis and Ruts. Yes it's a good representation of dates for displaying and sorting in the UI, or some text tool, CSV, whatever. However this is custom software. Storing dates as anything other than the provided types is wrong for many reasons. 8 digits can represent an invalid date. While sortable, it doesn't let you subtract dates or add/ subtract days. The code will have to have these packing/unpacking functions, which hurts performance and reduces reliability.

  • (nodebb) in reply to van Dartel

    anything that works in the long run is fantastic

    Nearly everything posted to this site "works", and is most definitely not fantastic.

    Anything other than ...

    '''' DateTime.ParseExact(sDate.ToString(), "yyyyddMM", CultureInfo.InvariantCulture); ''''

    ... is probably wrong. Maybe 2% of the time, it might be proper optimization. The other 98% is a programmer reinventing a wheel needlessly, and their go-to defensive is "for performance".

  • (nodebb)

    Sorry, I just want to see this thing work once:

    DateTime.ParseExact(sDate.ToString(), "yyyyddMM", CultureInfo.InvariantCulture);
  • Dennis (unregistered) in reply to Mr. TA

    Nope (and it's pretty terrible in a UI, where localized strings would be best). While in-program, the provided type would of course be best, but for storage and transfer YYYYMMDD or YYYY-MM-DD is much better than e.g. epoch timestamps. Sure, it takes up a little more space, but it is CLEAR that a date was instead of just randomly hitting 00:00. And it's instantly readable if you need to work with a problem.

    Of course some data/storage engines, like SQL, has a built-in format for dates and times, by all means use that if it is available. But for anything else? String formats. Always. For time, ISO8601 unless you have a very good reason to use something else.

  • (nodebb) in reply to Dennis

    So we agree? CSV - strings, obviously. UI - it depends, yes yyyymmdd is bad display format, but with - or / it's much better, and if you don't want to round trip to database to use native type sorting, the client can easily sort yyyy-mm-dd and cannot do so with month names and such.

    However all this is irrelevant. The question is, whether string dates should be used for storage in custom code. The answer: never

  • (nodebb) in reply to Jaime
    Anything other than ... 
    DateTime.ParseExact(sDate.ToString(), "yyyyddMM", CultureInfo.InvariantCulture);
    is probably wrong.
    Too bad even that is wrong, but this way it is easier to see that there is a problem. The date layout we have been talking about is year-month-day, so the correct code would be: 
    DateTime.ParseExact(sDate.ToString(), "yyyyMMdd", CultureInfo.InvariantCulture);
  • Jim Tonic (unregistered) in reply to Steve 
    if (oDataReader["DEB"] != DBNull.Value)
{
    DateTime dt = DateTime.Today;
    dt = UnpackDateC(dt, Convert.ToInt64(oDataReader["DEB"]));
}

    This usually gives a warning in the IDE you're using, but the compiler won't throw it away because UnpackDateC could have side effects.

  • Sole Purpose of Visit (unregistered) in reply to Mr. TA

    MVC.

    Ancient (as far as it goes), but still a trusty tool.

    Never confuse the model with the representation.

  • 🤷 (unregistered) in reply to Steve

    is it really true that you can declare a variable inside a block and have it visible outside the block

    No. You are thinking of PHP, not C#. In C# a variable is only visible inside the scope it was declared. So, if you want to handle, say, any dabase connection inside a catch or a finally, you have to at least set up the dbCon-object outside the try, or else there won't be any dbCon-object for you to handle in the catch or the finally.

Leave a comment on “Intergral to Dating”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article