• (nodebb)

    Count your blessings Islam doesn't allow interest bearing loans, or you would have to test against their moon based calendar going back to 7th century.

  • ray10k (unregistered)

    Obligatory watching after this: https://www.youtube.com/watch?v=-5wpm-gesOY

    Times and dates are harder than you think, even when you think they're pretty dang hard.

  • Andrew Miller (google)

    Most places changed in 1582. Sweden planned to do it gradually between 1700 and 1740, by omitting leap days. Then they had a war, and the plan got dropped. So they went back to the Julian calendar by having the only recorded February 30th in 1712..... Dates are hard.

  • Prime Mover (unregistered)

    "So Steffen grabbed one of the developers, and they sat down to go through the test cases. They chose the one which had the largest deviation from the payment provider's values, and walked through each month of the payment plan."

    So TRWTF is why he didn't do that frist?

  • LCrawford (unregistered)

    So TRWTF is why he didn't do that frist?

    I would say, why not have their 10,000 case test plan work from now through +400 years rather than dealing with calendar variations? Why did their loan provider's system accept loan calculation dates from the 1500s?

  • (nodebb)

    It's also, in addition to the oddities in Sweden, not a unique event, and the most recent civil (i.e. non-religious) calendar to change from Julian to Gregorian was in the 20th Century.

    It's worth noting that "the Western world" (as a whole) didn't change in 1582. The Roman Catholic world (most of it, anyway) changed then, but the British were notoriously uncooperative with the Papists, and waited until September 1752...

    $ cal 9 1752
   September 1752     
Su Mo Tu We Th Fr Sa  
       1  2 14 15 16  
17 18 19 20 21 22 23  
24 25 26 27 28 29 30
  • Prime Mover (unregistered) in reply to Steve_The_Cynic

    ... on which oddity (spoiler alert) rests the plot of Foucault's Pendulum by Umberto Eco.

  • SG (unregistered)

    There's a bridge in Lithuania that's claimed to have once been the longest bridge in the world, because it took thirteen days to cross. And that's because one side being Prussian and the other Russian, they were operating on different calendars for a few centuries.

  • TVJohn56 (unregistered) in reply to SG

    So, it took 13 days to cross one way, but you'd go back in time crossing the other way. Who needs a Delorean?

  • Andrew A. Gill (unregistered)

    The tests keep failing, so clearly we need to change the tests!

    I'm not saying we need to implement the most robust solution in every case, but the solution here should be to accomodate calendar shifts, not change your tests to avoid them.

    There are a lot more calendar changes than just Sweden or the 16th century. Most are pretty minor but the chances you'll bump into one in the next decade or two is non-negligable.

  • The Dave G (unregistered) in reply to Andrew A. Gill

    I have to agree. The tests did what they were supposed to do, find errors.

    I would not assign a high priority to fixing it, but make note that the code does not work properly for dates starting before whenever the world got on the same calendar (is it?)

    And now that I think about it, this is even more complicated. It's not just a matter of when but where the user making the payments is.

  • (nodebb) in reply to Prime Mover

    "... on which oddity (spoiler alert) rests the plot of Foucault's Pendulum by Umberto Eco." Wait, there's a plot in there?

  • David Jackson (unregistered)

    And of course St Teresa of Avila died during the night of 4th - 15th October 1582.

  • Hasseman (unregistered)

    Luckily times zones is not part of this. When you need to know that Riyadh had UTC+3h3 min between (I think) 1983 and 1987. Before and after 3h

  • Herr Jemand (unregistered) in reply to LCrawford

    Why did their loan provider's system accept loan calculation dates from the 1500s? Guess... maybe they decided not to reinvent the wheel, and used a general well-working dates handling library?

  • Zygo (unregistered)

    Choosing only dates in the 21st century conveniently avoids the once-every-4-centuries leap day rule for February 29, 2000.

  • David Jackson (unregistered) in reply to Zygo

    Date FROM the start of the 21st Century, not just the 21st Century. It goes up to the 30th Century, which should be far enough.

  • Fnord (unregistered) in reply to LCrawford

    Well, obviously because we don't know what adjustments to the calendar might be made in the future.

  • bruce.desertrat (unregistered)

    The RRTWTF (really REALLY True WTF) is that loan payments are calculated in months, not days. 12 payments per year. If your loan is being calculated in days, you pay the interest Vinnie the loan shark says.

  • Premature Optimisation Pills (unregistered)

    3 WTFs here.

    The main one is not using the provider's API for production. If they make a change, add fees, decide to hold their principal in dollars and track currency conversions (not sure how realistic that is), or if EU law changes, the developers of this software has to be on their toes to keep up with it. The resolution to this WTF, is in itself, a WTF. The wheel doesn't need reinventing.

    Second was that the initial test cases were clearly nonsense. All code has a contract, narrow or not. Expanding it unreasonably wide for the sake of perfectionism doesn't make any sense. Their job is to make something that works with an initial start time and a realistic end time (decades is a massive stretch, so should suffice). Their job is not to calculate loans in a period where the applicable law didn't exist, and neither did the currency. Tests should cover all cases in possible scenarios.

    The third WTF is the people on here claiming that the tests were good and the code should be amended to take medieval calendars into account, or that calendars are likely to change again in the lifespan of this software. The time that'd take to enact alone given full agreement by all participating nations would far exceed the lifespan of the software, let alone getting that agreement to begin with.

  • Barry Margolin (github)

    Shouldn't something like this have input validation? You can't originate a new loan on a date in the past.

  • Brian Boorman (unregistered) in reply to Premature Optimisation Pills
    The main one is not using the provider's API for production.

    It sounded like the provider's API was slow (or not real-time at all) and the website wanted to present real-time payment plan options to it's customers, kind of like those mortgage or auto-finance calculator websites.

    The provider may have other things they have to do before giving a binding payment plan option - for instance checking the credit score of the party looking to finance the transaction, that preclude offering real-time performance.

  • kaewberg (unregistered)

    Thank God the whole world is now in year ๒๕๖๔ (2564)

  • Lőrinczy, Zsigmond (github)

    Mind you, many program just use 'proleptic Gregorian calendar' meaning 'pretend Gregorian has always been used'.

  • Gumpy Gus (unregistered)

    Which makes one think as to how rental calculations were done back then. Were you charged for the regular month full of days, or just for the elapsed time? I bet the landlords wanted to charge for the regular month full of days.

  • Patrick (unregistered)

    "There were a handful of test cases that were off by hundreds of Euros." I know that as a story it should be a bit dramatic, but if all the failed test cases fall within 1582, shouldn't Steffan, being a professional historian, be competent to notice this in the first place? Or are there other cases that have nothing to do with calendar?

  • (nodebb) in reply to Steve_The_Cynic

    the British were notoriously uncooperative with the Papists, and waited until September 1752

    by which time our calendar was eleven days out, not ten.

  • (nodebb) in reply to Premature Optimisation Pills

    I remember working on the UK's computerised passport issuing system back in the 90's. We had a long discussion about how to calculate leap years for the purposes of date validation and future date calculation. The problem was complicated by the fact that the system we were working with had no date manipulation libraries and the code was written in Cobol making such calculations tedious. This was, by the way, when I discovered that the rule for leap years is not just "every year that is divisible by four".

    The discussion went on for about an hour until somebody pointed out that, if we just assumed every year divisible by four is a leap year, the software wouldn't break until 2090 (when calculation of the ten year passport expiry date would fail), by which time we all hoped to be retired.

  • Duke of New York (unregistered)

    The Greogrian calendar, introduced by Greogr the Greorgrian, aka Greogr the Baffler, Greogr the WTFter

  • (nodebb)

    I had fun trying to pronounce "Greogrian". I don't even want the typo crorected.

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

    Don't forget, those blasted English also mucked with the calendar the two years before to switch from a March 25th start of year to January 1st.

    The changeover involved a series of steps:

    December 31, 1750 was followed by January 1, 1750 (under the "Old Style" calendar, December was the 10th month and January the 11th) March 24, 1750 was followed by March 25, 1751 (March 25 was the first day of the "Old Style" year) December 31, 1751 was followed by January 1, 1752 (the switch from March 25 to January 1 as the first day of the year) September 2, 1752 was followed by September 14, 1752 (drop of 11 days to conform to the Gregorian calendar)

    https://libguides.ctstatelibrary.org/hg/colonialresearch/calendar

  • Jennifer Dehner (unregistered)
    Comment held for moderation.

Leave a comment on “Ten Days”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article