• 516052 (unregistered)

    To be fair, using a short to represent the year component in a date object makes sense. It's not like you'll ever need more than 8 bits of year. So this is less of a WTF and more of a Oh, neat.

  • (nodebb) in reply to 516052

    I think you meant 16 bits. 8 bits would allow only 256 possible values which while probably good enough for the lifetime of many systems, definitely feels needlessly risky.

  • (nodebb)

    As a non-American, the real WTF is the MM/DD/YYYY date format.

  • (nodebb)

    What a "weak" solution!

  • Tim (unregistered)

    Is that the same "Progress" 4GL I used in 1991 I wonder?

  • Flabberguest (unregistered)

    I may be missing something, but in the roll-over case the results would be "backwards", wouldn't they? The week number should always be on the left side of the subtraction, not on the right. The way it is, week 0 will result in week 26 (which is roughly ok), while week 26 yields week 0 of the previous year, which would be one and a half years ago?

  • (nodebb)

    Not sure if it's a mistake in Mirjam's memory, Remy's editing, or a real error in the original, but isn't 26 - v-weeknumber just plain wrong? If the start date is February 1, then week number is 5, and the result would be week number 21 (roughly mid-May). Unless 52 - 26 - v-weeknumber is right-associative, which would give the correct result but would be a definite language WTF.

    Addendum 2026-06-17 06:57: :hanzo:

  • 516052 (unregistered) in reply to Jonathan Lydall

    Indeed. My bad. I'd blame my years but that would just be a cliche.

  • MangusPI (unregistered) in reply to Jonathan Lydall

    Or rather, an actual WTF is non-Americans who cannot grasp the basic concept of their being more than one way to do things. Both formats have a place and logic behind them. This attitude of only yours being valid is frankly childish.

  • Hanzito (unregistered) in reply to Dragnslcr

    My thought exactly.

  • (nodebb) in reply to Jonathan Lydall

    And a reminder that there are different standards for week numbering
    https://en.wikipedia.org/wiki/Week#Other_week_numbering_systems
    noting that it seems USA uses two different ones.

  • (nodebb)

    OT: I bookmark comment pages I want to check on later, but TDWTFs comment page titles are all the same, so I have a single 'The Daily WTF: Curious Perver ...' bookmark. (And three with keyboard mash at the end.)

  • (nodebb)

    Agreed. Should probably be 52 - 26 + v-weeknumber

  • Pag (unregistered)

    The earliest possible date should be 01/01/-32768. It's either a copy-paste error or the person writing the docs is thinking the "most negative" value has to have the largest numbers possible. But even in negative years, January is still earlier than December.

  • Anonymous Coward (unregistered)

    I kinda don't hate the 52 - 26. Yes, it's mathematically unnecessary. But at a glance, I know exactly what's happening where I might have to think a sec if I saw 26 instead.

  • ttlanhil (unregistered) in reply to MangusPI

    As a non-American, yes, there are multiple ways to do dates. There's the international standard yyyy-mm-dd (which is ideal for a number of reasons) There's the older dd/mm/yyyy (you're scanning left to right and want to see date first - not as good, but okay) There's d/m/yy (or some mix of which fields are abbreviated) which isn't as good, and can sometimes cause problems, but if you want quick'n'dirty it's there...

    Then there's mm/dd/yyyy which never makes sense unless you grew up with both it and American exceptionalism. Try telling time as min:sec:hour and see how confusing that gets if you want middle-endian data. Note, if you instead do mon dd yyyy (e.g. July 4 2026) and you speak that way (i.e. you say "July 4" or "July 4th") then I'll accept that, in name form. But not numeric.

  • (nodebb) in reply to HXO

    There may be multiple week-numbering standards, but subtracting 26 (with wraparound) should be an OK way to go back half a year in all of them.

  • Joe (unregistered)

    Most of the people complaining about mm/dd/yyyy prefer to use dd/mm/yyyy which is funny because if you're on this site, you should know that yyyy/mm/dd is vastly superior because it can be sorted as a string and for the most part nobody gets confused about which component is the month and which is the day (some people will be confused no matter what).

  • Jaloopa (unregistered) in reply to Joe

    I exclusively use yyyy/dd/mm, just to be contrarian

  • Someone else (unregistered)

    As someone who's company's primary product is based on Progress ABL... I'm sorry to hear there is someone else that works in it. I should check my codebase to see if this is us or not, but I'm pretty sure it's not.

  • Darren (unregistered)

    Seeing that code gave me flashbacks of having to debug some code that a supplier provided that didn't work - and they couldn't figure out why!

    They wrote it but couldn't fix it to make it do what they designed it to do. So I - who'd never used the language before - had to help out to fix it.

  • MangusPI (unregistered) in reply to ttlanhil

    I prefer yyyy-mm-dd (or variations of delims with that order) myself, especially for filename and similar sorting purposes.

    FWIW, I have seen people outside of the States using mm/dd/yyyy, citing that it's useful to see the month first as the dom is less useful without knowing that and the year at the end when the year isn't important to the context. I also believe that comparing it to 'min:sec:hour' vs 'hour:min:sec' is a bit of a apples vs oranges fallacy. I do appreciate having a natural progression, especially as a numbers and tech guy, but it's still two separate categories of horology, and like with anything else, you can't just say "if it works best in category A, it must also be the best for B and that's that."

  • Gerco (unregistered)

    Yes, @Tim. Progress ABL used to be called 4GL. It now supports classes, integrates with .NET and various other "modern" niceties.

  • COBOL Dilettante (unregistered)

    I exclusively use Julian dates. Months are a Pagan superstition that has no place in the modern world.

  • (author) in reply to MangusPI

    That is interesting, I never thought about the fact that mm/dd/yyyy sorts the fields in order of salience. Year is frequently uninteresting, day requires the context of month to be valuable. It actually does make sense, in its own weird way.

  • (nodebb) in reply to Remy Porter

    Year is frequently uninteresting

    Except when v-weeknumber < 26

    This code looks like a less than impressive way to find the "date of the Monday (or Sunday?) of the week that was 6 months ago" since that was VERY important to some business process that was designed in 1937.

  • (nodebb)

    On the subject of mm/dd/yyyy : https://xkcd.com/1179/

  • Loren (unregistered)

    Add me to those who think mm/dd/yy exists because the mm is usually the most important field. Worked fine in the old days.

    But I find myself very surprised at the date range. Clearly they used an 8-bit/8-bit/signed 16-bit, probably all wrapped up as an unsigned 32-bit. But why is the start date 12/31/-32768 and not 1/1/-32768? (And, yes, that's probably wider than anyone will use. The cost of supporting that is effectively zero, though, so why not? 16-bit values are too narrow for dates, chipping off a bit or two from a 32-bit value costs more performance than any savings, so why not expose the whole range?)

  • A Human (unregistered)

    How about mmm/yy/dd (as in JUL-26-27)?

    Ok, in all seriousness I use iso8601 for everything and will refuse to use any other date format.

  • Meir (unregistered)

    Another way to look at the advantage of mm-dd-yy is to think of the number of possible values for each, from least to most: 12, 31, 100.

  • Kotarak (unregistered) in reply to Jonathan Lydall
    Comment held for moderation.
  • (nodebb)

    Eh? Never heard of it. Looks to me like an even worse language than BASIC.

  • The Masked Man (unregistered) in reply to Tim

    Yes. Progress was once a product of the Data Language Corporation. It was successful, so now the company is called Progress… but not that successful, so the product was renamed OpenEdge. See https://en.wikipedia.org/wiki/OpenEdge_Advanced_Business_Language

  • A.N.O Nymos (unregistered)

    I wonder if the original code also handled the cases where a year (especially the previous one) had 53 weeks? As the code stands now (not counting the possible math error mentioned above), if the current week is less than 26, the calculated week number will be off by 1.

  • 516052 (unregistered) in reply to Joe

    dd/mm/yyyy is best because it sorts the data based on how people divide up time in a logical way. You wouldn't write second:hour:minute. yyyy/mm/dd works as well but is less intuitive and frankly really smells like someone in ISO thought that the american way was dumb but couldn't accept the european way for fear of making the americans buthurt so he made up a third way.

  • Anonymous ABL developer (unregistered)
    Comment held for moderation.
  • A.N.O Nymos (unregistered) in reply to 516052

    How is dd/MM/yyyy in any way logical in a way that doesn't apply to yyyy/MM/dd? It's only really useful if you want to see month-over-month results or year-over-year (01/01/2026 is followed by 01/01/2027, is followed by 01/02/2026). As someone who frequently works with tables that have many dates in them, our customers usually want to sort them by date (i.e.: 01/01/2026 -> 01/02/2026 -> 01/01/2027).

    Then again, I usually sort using the number of ticks, so the actual formatting is purely cosmetic and doesn't really matter. Only with file-names do I insist on using yyyyMMdd for ease of sorting.

  • 516052 (unregistered) in reply to A.N.O Nymos

    It's all to do with mental optimization and ordering.

    Date strings are a data format optimized for human reading. As you say, if we want to present data in a computer oriented format we use timestamps.

    As a general rule when creating a human readable data format you want to sort the data such that the likelihood of a certain piece of information being accessed matches the expected read order of the users culture. This minimizes the amount of cognitive effort the reader needs to invest by allowing him to short circuit to the information he is looking for as often as possible. Which in turn makes the experience mentally more comfortable.

    As westerners tend to read from top-left toward bottom-right that means that for them you want your most important and commonly accessed data to be on the top left with both declining toward the bottom right.

    As a general rule the vast majority of date lookups in everyday use by common people going about their lives are going to be questions about the specific relationship between day and date in the immediate future, followed closely by the immediate past. That is to say questions like: "What date is it today?", "What day is the 3rd?", "What date was last friday?"

    Month data is accessed more rarely but still regularly. And year data is only really accessed in the context of an entire date stamp when looking at historical data.

    So it makes sense that the ordering of the string would match that.

    You can try this out your self. Write the same date in dd/mm/yyyy and yyyy/mm/dd and than use it in the sort of everyday query that you'd normally do. You will notice that the later works but just feels ever so slightly more difficult mentally.

  • 516052 (unregistered)

    It's analogous to how you order your closet. You want your everyday wear to be front and center at between eye and elbow level for easy access. And you keep your fancy clothes that you take out once a year for a wedding or funeral or something way in the back.

Leave a comment on “Weekly Calculated”

Log In or post as a guest

Replying to comment #700753:

« Return to Article