Hacker News Reader

Comment by zie | Hacker News Reader

How we solve that problem is a Calendar table in the DB, and some human somewhere is required every year to update the calendar with the various holidays and what not. Then we just look up if it's in the list or not. It's a human problem anyway, and then when someone decides, wouldn't it be spiffy if we did a day of staff training on X day and did a reduced service? Sure, whatever, just put it in the calendar and blamo, accounted for properly.

View on HN

I literally saw this at my first work 20 years ago. You generate most by script and just add those few odd public holidays manually, much easier to have a person spend 5 mins once every year rather than some smart script with 20 not-so-well-handled corner cases and 7 bugs.

Oh goodness no, we don't generate ANY of it, we require the HR dept to own the calendar data. They can copy from the previous years calendar if they want as a button in the UI, but I honestly have no idea if they use that button.

Like I mentioned in a diff. comment, we generate all the official calendars of the org from this data. We print them, we generate .ics, etc.

I've seen this done multiple times too. It works until the human forgets about it, or knowledge is lost through collective organisational forgetfulness or churn. And the outages still happen because the lookup fails at some point.

Does it end up better or worse in practice than the pure computational approach? A system with the same faults as the system it replaces could still be an improvement if they occur less often.

What we do to counteract that problem, is we generate organization wide calendars from this list. We provide .ics feeds for our organization, etc. ALL of it comes from this calendar, so if you want to know when a payday happens, you are just looking at a view of our calendar. If you want to know what the official org holidays are, you are looking at a view of our calendar. I mean it might display in Google calendar or Apple Calendar or whatever, but we are the data source.

So when a mistake happens, every employee that cares about that date will find someone to complain about it to, and ultimately someone somewhere goes, oh bother, we forgot to update the Calendar, and they promptly fix it.

Plus we avoid all blame, as it's very clear that we don't invent the calendar data. For us the HR dept is in charge of maintaining the calendar.

This is also how we do it, but it’s the “obvious” solution the moment you realize that holidays don’t fall on the same days each year. It’s simple enough to predict the day they’ll fall on, but why bother with that when it takes someone 2 minutes every year to just enter these days in?

And then some king dies in some country and it's a national holiday the next week, and the data entry guy is in sick leaves and your table isn't updated to close trading... happened to the bank I work in, wasn't funny.

I don’t think there’s an algorithm accurate enough to predict the death of that king down to a specific day.

You’re still going to need that data entry guy. (Plus the two more that is the root problem)

Well, there is one algorithm accurate enough.

Regicide

How would this surprise one-off holiday be accounted for programmatically? Does the government provide an API you can ping every day? Or you scrape the news feeds and feed it through ChatGPT?

Stuff like this is often officially communicated through some kind of government newsletter. Other times it's just custom and doesn't have a formal notification.

For the UK at least, there’s https://www.gov.uk/bank-holidays.json

Personally this (along with things like address lookup) are things that I consider a government should always provide. Consistent data.

What does "bunting" mean in the date entries?

Bunting just means decorations, the value is true when the government recommends decorating for the holiday. It's reserved for celebrations, so events like the queens funeral have it set to false.

Isn’t there black bunting?

You do what you can, and then insure the remaining risk away.

Well-designed human-involved processes try to reduce “once in a blue moon” edge-cases, sometimes at the cost of overall optimisation, in large part because people will forget how to do them, people will forget to keep building in redundancy, etc.

> data entry guy is in sick leaves

if this data entry was so important, why is there only one guy responsible for it? where's the backup? where's the redundancy?

How we actually solve that problem (at least over here in Poland) is by excluding the weirder holidays from the electronic schedule altogether and deactivating all the arrival time boards and such. If you're lucky, there are cardboard signs explaining all the holiday rules at each stop, there may also be a PDF on the operator's website.

So you basically copy the computation of someone else. But that doesn’t solve the problem of the computation.

It needs to be like this. There is an underlying computation. You can cache the results of this computation in a DB table.

Sometimes, ad hoc things happen in our culture. Spurious bank holidays get added on a day’s notice in exceptional situations. These can be inserted into the cached DB. There is no calculation to back them.

Bank Holidays, days of mourning, or a pandemic and war. The systems should be done so that the calendar can be agile like that.

> days of mourning

This is a big one. And you don't get much notice, maybe a day or two. Typical ones in the US are death of a President or prominent Senator (I _think_ we had one for John McCain). Much easier if you can insert the holiday in a lookup table and have all your systems adapt.

Software people hate hearing when the solution to a problem is anything other than more, more complex, software.

I can’t prove it, but suspect a lot of business processes would be overall more efficient with less automation. Once you factor in the cost of automation, the cost of maintenance, the cost of un-fucking the computerized system when it manages to make a mistake “at scale”, et c.

It’s not always a computation problem.

Unexpected bank holidays (happened to me in 2002 during a financial crisis), official days of mourning, etc. Nothing to compute there: a government declares a holiday and you just enter it into the table.

Sure, you can compute Easter (you can just look up Knuth’s explanation of the algorithm for this…), but you can’t compute government decrees.

Not yet ;)

I work with finance data and we ended up building just that + and API. Almost everything is done automatically though. Some languages have a function to calculate Easter

We 100% refuse to do that, no way. The data in the calendar table is owned by HR. They update it. If they farm it out to their receptionist, fine with me. It's not a complicated task, but it's just complicated enough that a computer shouldn't be doing it.

We do generate all the official calendars though, so we have print options to print various views of it(paydays, etc) and we also provide .ics feeds for Google/Apple Calendar, etc.

Sounds like a simplified form of the generic idea of a rules engine.

Its a look up table.

Reply on news.ycombinator.com