Julian date
it's there for a reason - use it !
A programming blunder appears to have landed the cash-strapped Co-op Bank an unexpected bill for £110m. In its financial report [PDF] for 2013, which last week revealed a £1.3bn loss, the bank said it had to stump up nine-figure "costs relating to breaches of the Consumer Credit Act". Specifically, the scandal-hit bank noted …
used to run time travel environments for this kind of thing, testing customers through their contract life cycles, devs and testers could just roll the box forever forward - though we did get some very interesting errors when a user accidently set a 5 date year. This was some time ago...
Some bloke run it last year, maybe put a recurrent reminder in their outlook to run the batch again in 360 days. They got a golden handshake, provided a binder of procedures including all the one-shot-one-off-become-recurrent-to-be-automated-one-day-when-we-have-time scripts to his replacement and that one fell threw the crack. Some manager still around had a vague memory about when the last time that was run, probably just before a bank holiday weekend, told their resident BOFH about it, who ran it a year later, after aforementionned bank holiday weekend, ergo, 3 days late...?
Ok boys - so about we post examples of how WE would code setting a date to current date + 365.
To add my 2c - I'd first get the requirement defined. Do they really mean 'same time next year' and it has been defined incorrectly as 365 ? If so - just change the year to +1 and job done. Even it is WAS really +365 days if they were happy with it being 1 off, it still could be the acceptable solution.
Julian dates... really ?
I have the answer!
// work out when the next report is due:
next_report = add_365_days();
Seriously, though, I'd probably do something like:
if (days_since(last_date) == 365) {
// send
}
No, actually, this is more readable:
if (ready_for_report()) {
// send
}
Where do I collect my prize?
Nope, no prize for you (or anybody else who suggested a solution) because you all forgot about weekends and other non-working days. A more correct solution would be:
Take the day and month of the contract start date
Add the current year to get a date in the current financial year.
If its a working day, you're done.
Otherwise step back a day and and check again. Keep doing this until you've found a working day.
Then have a word with your employer's tame contract lawyers to make sure you don't need to send the statement even earlier to allow for postal delivery and/or bank processing delays.
But sometimes the library is broken. We encountered a bug in the date functions in SCO's C library. (I can't remember whether it was OpenServer or UnixWare.)
If you really care about correctness it's a good idea to do your own implementation and compare it with someone else's implementation, thereby perhaps finding bugs in both. Some date functions can be tested exhaustively as the number of possible inputs, or inputs that you care about, is less than a few thousand million. So take ten minutes to do that. However, none of this protects against someone misunderstanding how the function should be used.
I wouldn't be surprised if Excel had anything to do with it. It has at least one date (infamous leap year issue) bug that MS refuses to fix for over two decades now.
It wouldn't be the first time that someone relying on Excel for serious calculations got bitten by it. http://www.eusprig.org/horror-stories.htm
The whole problem with dates and times is exactly that. Everyone thinks they understand how it works and it should therefore be easy to code.
In reality working with times and dates is extremely complex but, because few people appreciate this complexity, things go wrong all the time. Every year there are at least one or two major stories of companies screwing up timezone offset calculations, daylight savings time switches or other unexpected date/time behaviour in their products inconveniencing millions of customers.
I have a weekly conference call with someone in Phoenix, Arizona. Phoenix is a tough one because half the year Phoenix is in Mountain Time, the other half it's in Pacific Time. Because European and US daylight savings time switches are not aligned we have a window of a few weeks twice a year where we know the meetings in our calendars are incorrect because Exchange and Lotus Notes can't agree on what time it is where.
Then there are places with a half timezone offset (i.e. +07:30), places that switch from one side of the dateline to the other, Israel where DST dates are a political instrument so they can change with just a few months notice, UTC and GMT not being the same although many people believe they are etc. etc.
It's a recipe for disaster, precisely because people mistakenly think it's straightforward.
Indeed.... That's why I posted it. We've had a couple of customers (usually subject to military dictatorship - it's never fun being on site, when coup happens) who've called in and told us "the boss decreed we'd have daylight savings this year", a couple of days before the fact. It's never a laughing matter.
In short, GMT is a time-zone, and UTC is a timekeeping system:
In short, GMT is a time-zone, and UTC is a timekeeping system:
Err, no. GMT is the natural observed time as modified by the equation of time (hence the "mean", since it is an averaged over the year to compensate for the Earth's elliptical orbit). UT1 is basically GMT with a slightly sharpened-up definition because the original was a little vague by modern standards of precision.
UTC is the time as determined by atomic clocks and needs leap seconds inserting periodically to keep it within 0.9 seconds of UT1. For most everyday purposes you can consider the GMT and UTC to be the same but you don't get leap seconds in GMT.
Phoenix, Arizona is always on Mountain Standard Time, i.e.UTC-7. This may overlap with some other adjacent timezones now and again, but Phoenix doesn't change its clocks at all.
The complications are solely due to everyone else gyrating back and forth between daylight saving, and the idiotic decision to move the US out of sync with the DST transition in the rest of the world
You're right that they don't change clocks. However, considering other states do change clocks they consider themselves to be on Pacific Time half of the year and on Mountain Time the other half.
All semantics of course, but very confusing for computers nonetheless...
I've had lots of fun with finance's definition of time intervals. Mind you, a year is not always 365 days, all months don't have 30 or 31 days, four weeks is not a month, 20 working days are not always four weeks, all years don't start the first of January, etc... Mix that with such minute details such as "which day of the week is the first" (on which country?) and local/bank holidays and you have the potential to a lot of edge cases that may never be tested properly.
Let's not even start talking about the fun of rounding dates. "At least one month outstanding" may mean many different things to different types and mixing that with financial closure calendars introduces endless WTF moments...
> A programming blunder ... were sent out late – specifically, 368 days after the previous annual statements
Surely you mean a TESTING blunder: that the code (or more likely: the integrated environment in which it was run) was not put through a sufficiently realistic set of test scenarios. Or if it was, then nobody looked at the results.
A more interesting possibility is that the code was tested AND the bug was found. But t'management thinking was: "it won't affect us for a year ... there's plenty of time to sort it out later". But somehow that never happened.
Dates and calendars are, indeed, difficult, but how does one make a 3 day mistake? I am genuinely curious. The 365 day rule indicates that we are talking about calendar days, not business days vs. holidays, thus the problem is simpler. Anything related to leap years would cause a one day delay. Even pretending that there are 31 days in February is more likely to send the reports 3 days earlier, not 3 days later. The mind boggles...
I'd suggest it is a batch job that runs once a week - that'd do it.
not only that, but it's exactly the sort of crappy requirement that businesses come up with:
- run batch job once a week on monday morning: If >364 days, send out letter.
Result:
coded by (offshore?) monkeys that haven't the sense to ask 'er.. u sure about this ?'
and tested by (offshore?) monkeys who blinded test on the requirements (which are clearly met).
job done.
Three days sounds like a weekend shift.
I ran into this problem when trying to program my credit card payments in my online payment service. Nominally they are due the same day every month. Except if the day falls on the weekend. For deposits banks tend to shift to the Monday after the deposit hits. For withdrawing they shift to the Friday before the due date. So if you want to be sure your payment gets there on time, you have to shift your send date up 3 days from when you would normally send it. Even then they dick around with the due date because of the 30/31 day issue so I finally gave up and started sending based on when paychecks hit. Even at that I still have to program the three day shift account, but since paychecks are consistent (10 and 25th for me) that works.