And we also need localization. Each country can have their own holidays

And we need groups of locales for teams that are split across multiple locations; e.g.:

  new_date = add_workdays(
    workdays=1.5,
    start=datetime.now(),
    regions=["es", "mx", "nl", "us"],
  )

Hopefully "es" will have Siesta support too.

Might be better to calculate them separately for each locale and then tie-break with your own approach (min/max/avg/median/etc.)

Don't forget about regional holidays, which might follow arbitrary borders that don't match any of the official subdivisions of the country. Or may even depend on the chosen faith of the worker

Pulaski day in Illinois. Or Reds Opening Day in Cincinnati.

> Workdays!

This is javascript, not Java.

In JavaScript something entirely new would be invented, to solve a problem that has long been solved and is documented in 20+ year old books on common design patterns. So we can all copy-paste `{ or: [{ days: 42, months: 2, hours: "DEFAULT", minutes: "IGNORE", seconds: null, timezone: "defer-by-ip" }, { timestamp: 17749453211*1000, unit: "ms"}]` without any clue as to what we are defining.

In Java, a 6000LoC+ ecosystem of classes, abstractions, dependency-injectables and probably a new DSL would be invented so we can all say "over 4 Malaysian workdays"

JavaScript Temporal. Not sure knowing what a "workday" is in each timezone is in it's scope but it's the much needed and improved JS, date API (granted with limited support to date)

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

But you know that Java solution will continue working even after we no longer use the Gregorian Calendar, the collapse and annexation of Malaysia to some foreign power, and then us finally switching to a 4-day work week; so it'd be worth it.

It probably won’t work correctly from the get go. But it can be debugged everywhere so that’s good.

... and since it was architectured to allow runtime injection-patching of events before they hit the enterprise-service-bus, everyone using this library must first set fourteen ENV vars in their profile, and provide a /etc/java/springtime/enterprise-workday-handling/parse-event-mismatch.jar.patch. Which should fix the bug for you.

You can find the patch files for your OSs by registering at Oracle with a J3EE8.4-PatchLibID (note, the older J3EE16-PatchLib-ids aren't compatible), attainable from your regional Oracle account-manager.

This isn’t even remotely funny.

I am laughing. I'm not even near the end of this thread.

And least one of those environment can contain template strings that are expanded with arguments from request headers when run under popular enterprise java frameworks, and by way of the injection patching could hot load arbitrary code in runtime.

A joke should be funny though, not just a dry description of real life, so let's leave it at that. We've already taken it too far.

In before someone thinks it's a joke, the most commonly used logging library in Java had LDAP support in format scripts enabled by default" (which resulted, of course in CVE)

There's an extra digit in your timestamp.

Ah but you don't know how far in the future I intended it to be :)

Why would it get pulled in over the weekend? What automatic deployments are you running if there also isn't a human working to get it out?

Do you run automatic dependency updates over the weekend? Wouldn't you rather do that during fully-staffed hours?

When I worked in Finance our internal Date extension did actually have Workdays that took into account Stock Market and Bank Holidays.

…now imagine a list of instruments, some of which have durations specified in days/weeks/months (problems already with the latter) and some in workdays, and the user just told your app to display it sorted by duration.

Me too, it was just a constant filled with bank holidays for the next 6 years

I tried to write this function in Power Query (Excel hell). Gave up after an hour or so.

Nah, working hours and make global assumptions of 0900-1230/1330-1730, M-F, and have an overly convoluted way to specify what working ours actually are in the relevant location(s).