DEV Community: Nomad Wozo

Handling Moving Holidays in a Business-Day Calculator: Data Sources and Edge Cases

Nomad Wozo — Thu, 12 Nov 2026 09:19:01 +0000

Fixed-date holidays are easy. You store 12-25 and you're done. The holidays that cause real bugs are the ones that move every year: Easter, Lunar New Year and Eid. On top of that, the substitute-day rules move holidays a second time when they land on a weekend.

This post covers where I get the dates, which ones I compute and which I never compute, and what broke my tests. All the code below is plain Python (stdlib only), and I ran it against the live official feeds before writing this up.

Rule 1: Compute only what is actually defined by math

Western Easter is pure arithmetic. The Anonymous Gregorian algorithm (Meeus/Jones/Butcher) works fine:

def western_easter(y):
    # Anonymous Gregorian algorithm (Meeus/Jones/Butcher)
    a, b, c = y % 19, y // 100, y % 100
    d, e = b // 4, b % 4
    f = (b + 8) // 25
    g = (b - f + 1) // 3
    h = (19 * a + b - d - g + 15) % 30
    i, k = c // 4, c % 4
    l = (32 + 2 * e + 2 * i - h - k) % 7
    m = (a + 11 * h + 22 * l) // 451
    month = (h + l - 7 * m + 114) // 31
    day = (h + l - 7 * m + 114) % 31 + 1
    return date(y, month, day)

Even so, I don't trust my own math until I've checked it against a government list. The UK publishes its bank holidays as JSON, so the check is cheap:

official_good_fridays = {e["date"] for e in uk["england-and-wales"]["events"] if e["title"] == "Good Friday"}
for y in (2026, 2027):
    gf = western_easter(y) - timedelta(days=2)
    print(y, "computed Good Friday", gf, "| in gov.uk list:", gf.isoformat() in official_good_fridays)

Lunar New Year and Eid are a different story. Both depend on lunar calendars and, for Eid, on official announcements. As of late October 2026, I couldn't find official Gulf dates for Eid in 2027. So the rule in my code is simple: no published date, no holiday. A provisional date is flagged as provisional and never silently treated as final.

Rule 2: "The country" is the wrong key

Here's the UK feed split by division:

# 1) UK: one country, three holiday lists
uk = fetch_json("https://www.gov.uk/bank-holidays.json")
for division in ("england-and-wales", "scotland", "northern-ireland"):
    easter = [e["date"] for e in uk[division]["events"]
              if e["title"] in ("Good Friday", "Easter Monday") and e["date"].startswith("2027")]
    print(f"{division:18} 2027 Easter closures: {easter}")

England & Wales and Northern Ireland close on Easter Monday 2027. Scotland doesn't. If your holiday table is keyed by GB, one of those groups will get the wrong deadline. Key it by the jurisdiction that actually publishes the list.

Lunar New Year has the same problem across countries. Hong Kong's 2027 list starts on February 6:

# 5) Lunar New Year: same festival, different first day
print("HK 2027 holidays in Feb:", [(d, s) for d, s in events.items() if d.startswith("202702")])

Korea's official 2027 calendar, published by the Korea AeroSpace Administration (KASA) with data from the Korea Astronomy and Space Science Institute (KASI), puts Seollal (lunar 1/1) on February 7. Same festival, different first day. Don't share one "Lunar New Year" date between countries.

Rule 3: Read official feeds defensively

My first attempt at parsing Hong Kong's official JSON feed crashed:

json.decoder.JSONDecodeError: Unexpected UTF-8 BOM (decode using utf-8-sig)

The file starts with a byte-order mark. The fix is one argument:

def fetch_json(url):
    with urllib.request.urlopen(url, timeout=30) as r:
        raw = r.read()
    # The Hong Kong feed starts with a UTF-8 BOM; plain json.loads(raw.decode()) fails on it.
    return json.loads(raw.decode("utf-8-sig"))

Also, the feeds aren't all shaped alike. The UK feed is {division: {events: [...]}}. Hong Kong's is a jCal-style vcalendar[0].vevent[] with dtstart as ["20260403", {"value": "DATE"}]. Write a small adapter per source and test it against real files.

Rule 4: Substitute-day rules collide

This one bit me. In Hong Kong in 2026, Easter Monday is April 6 and Ching Ming Festival falls on Sunday, April 5. Here's what the official feed lists:

# 3) Hong Kong: substitute days collide
hk = fetch_json("https://www.1823.gov.hk/common/ical/en.json")
events = {e["dtstart"][0]: e["summary"] for e in hk["vcalendar"][0]["vevent"]}
for d in ("20260403", "20260404", "20260405", "20260406", "20260407"):
    print(d, events.get(d, "-"))

The government didn't just shift Ching Ming to Monday. Monday was already Easter Monday, so the extra day landed on Tuesday, April 7. A naive "Sunday → Monday" rule loses a day:

# 4) A naive "Sunday -> next Monday" rule gets that week wrong
def naive_observed(holidays):
    out = set()
    for h in holidays:
        out.add(h + timedelta(days=1) if h.weekday() == 6 else h)
    return out

def observed_next_free_day(holidays):
    """Sunday holiday -> next day that is not already a holiday (or a Sunday)."""
    out = set(h for h in holidays if h.weekday() != 6)
    for h in sorted(holidays):
        if h.weekday() == 6:
            d = h + timedelta(days=1)
            while d in out or d.weekday() == 6:
                d += timedelta(days=1)
            out.add(d)
    return out

easter = western_easter(2026)
base = {easter - timedelta(days=2), easter - timedelta(days=1), easter + timedelta(days=1),
        date(2026, 4, 5)}  # Ching Ming 2026, per the HK gazette
print("naive   :", sorted(d.isoformat() for d in naive_observed(base)))
print("next-free:", sorted(d.isoformat() for d in observed_next_free_day(base)))

The naive version shifts Ching Ming onto April 6, which is already a holiday, and the set quietly merges the two. That's three days off where the official calendar has four.

observed_next_free_day gets this case right, but I don't ship it as the source of truth. Substitute rules differ by country, and they're written in law, not in code:

US federal (OPM): for most federal employees, a Saturday holiday is observed the Friday before and a Sunday holiday the Monday after.
UK: if a bank holiday falls on a weekend, a substitute weekday becomes a bank holiday, normally the following Monday. The 2027 list has December 27 and 28 as substitutes for Christmas and Boxing Day.
Korea: substitute days apply to listed holidays. The 2027 calendar has substitutes on Feb 9, May 3, Jul 19, Aug 16, Oct 4, Oct 11 and Dec 27.
UAE: the government portal says that under Cabinet Resolution No. 27 of 2024, a public holiday can't be moved to another day if it falls on a weekend or on another holiday. So a weekend holiday is simply lost.

So my rule ended up being: use the published list, including its substitute days, and use rule-based code only as a test oracle. If my rule and the government list disagree, the list wins and I go read the law.

The output

Here's the full run from the script, unedited:

england-and-wales  2027 Easter closures: ['2027-03-26', '2027-03-29']
scotland           2027 Easter closures: ['2027-03-26']
northern-ireland   2027 Easter closures: ['2027-03-26', '2027-03-29']
2026 computed Good Friday 2026-04-03 | in gov.uk list: True
2027 computed Good Friday 2027-03-26 | in gov.uk list: True
20260403 Good Friday
20260404 The day following Good Friday
20260405 -
20260406 The day following Ching Ming Festival
20260407 The day following Easter Monday
naive   : ['2026-04-03', '2026-04-04', '2026-04-06']
next-free: ['2026-04-03', '2026-04-04', '2026-04-06', '2026-04-07']
HK 2027 holidays in Feb: [('20270206', "Lunar New Year's Day"), ('20270208', 'The third day of Lunar New Year'), ('20270209', 'The fourth day of Lunar New Year')]

Edge cases worth a test each

A computed holiday (Easter) matches the official list for every year you support.
Regional splits: Scotland vs England & Wales on Easter Monday.
The same festival starts on different dates in different countries (Lunar New Year 2027: HK Feb 6, Korea Feb 7).
Two holidays compete for the same substitute day (HK, April 2026).
A holiday that falls on a weekend gets no substitute at all in some countries.
An announced-later holiday (Eid) is missing or provisional, and the UI says so.
Feed parsing: BOMs, different JSON shapes, date-only strings with no time zone.

What's the weirdest holiday edge case you've hit? I'm collecting them.

Sources (checked October 30, 2026): GOV.UK bank holidays JSON, Hong Kong 1823 holiday feed, GovHK 2026 holidays, KASI 2027 calendar data, OPM federal holidays, UAE public holidays (u.ae), KASA 2027 calendar announcement.

Note: I drafted this with help from an AI assistant. I ran the code and checked the dates against the sources above myself.

Disclosure: I build WorkdayMap, a free business-day calculator where you can enter these closures and see every counted and skipped day.

Rounding Money in JavaScript: Why Loan Schedules Drift by a Cent

Nomad Wozo — Wed, 11 Nov 2026 09:13:51 +0000

Build a loan amortization table in JavaScript and you'll often get one that looks right until someone adds up a column. The interest column totals $327.96, the summary row says $327.97, and the balance ends at $0.05 instead of zero.

None of that is a bug in the loan formula. It's a rounding problem, and it comes from four places: how numbers are stored, how they're printed, which rounding rule you use, and when you round. Every output below is from actually running this code on Node 24. The loop snippets are trimmed slightly for length.

1. The decimal you typed isn't the number you got

JavaScript numbers are IEEE 754 double-precision binary floats. Most decimal fractions, including most cent amounts, can't be stored exactly, so you get the nearest representable value:

console.log(1.005 * 100);                    // 100.49999999999999
console.log(Math.round(1.005 * 100) / 100);  // 1
console.log((1.005).toFixed(2));             // "1.00"
console.log((1.005).toPrecision(20));        // "1.0049999999999998934"

So "round to cents" rounds 1.005 down, because the stored value really is a hair below 1.005. MDN's toFixed page has the same trap with (2.55).toFixed(1) returning "2.5".

A common patch is to add Number.EPSILON before rounding. It helps for small numbers and quietly stops working as the numbers get bigger, because EPSILON is tiny compared to the gap between floats at that size:

const nudge = (x) => Math.round((x + Number.EPSILON) * 100) / 100;
console.log(nudge(1.005), nudge(10000.005)); // 1.01 10000

One more surprise: Math.round sends exact halves toward +∞, not away from zero.

console.log(Math.round(2.5), Math.round(-2.5)); // 3 -2

That matters as soon as refunds or negative adjustments show up.

2. Intl.NumberFormat is for display, and it rounds its own way

Intl.NumberFormat is the right tool for turning a number into $1,234.57. Just keep in mind that it rounds too, and it doesn't have to agree with toFixed:

const usd = new Intl.NumberFormat('en-US', { style: 'currency', currency: 'USD' });
console.log(usd.format(1.005), (1.005).toFixed(2)); // $1.01 1.00
console.log(usd.resolvedOptions().roundingMode);    // halfExpand

Same value, two built-ins, two answers. Per MDN, the default roundingMode is "halfExpand" (ties away from zero), and you can ask for others, including "halfEven":

const usdEven = new Intl.NumberFormat('en-US',
  { style: 'currency', currency: 'USD', roundingMode: 'halfEven' });
console.log(usd.format(0.125), usdEven.format(0.125)); // $0.13 $0.12
console.log(usd.format(0.135), usdEven.format(0.135)); // $0.14 $0.14

The fix for both sections is the same: don't do money math on floats, and don't let a formatter decide your amounts. Store integer cents and only format at the edge:

const fromCents = (c) => usd.format(c / 100);
console.log(fromCents(123456789)); // $1,234,567.89

Integers are exact in a Number up to Number.MAX_SAFE_INTEGER (9,007,199,254,740,991). That's about $90 trillion in cents. Use BigInt if you multiply cents by rates and want the intermediate products exact too.

3. Half-up vs. banker's rounding

When the exact result lands precisely on half a cent, you need a rule. Here's one helper that rounds an exact fraction of two BigInts either way:

function divRound(num, den, mode = 'halfUp') { // BigInt, den > 0
  const sign = num < 0n ? -1n : 1n;
  const a = num < 0n ? -num : num;
  let q = a / den;
  const r2 = (a % den) * 2n;
  if (r2 > den || (r2 === den && (mode === 'halfUp' || q % 2n === 1n))) q += 1n;
  return sign * q; // halfUp = half away from zero
}

Round ten amounts that are all exactly x.5 cents (0.5¢, 1.5¢ … 9.5¢, which add up to 50¢):

halfUp   cents: 1,2,3,4,5,6,7,8,9,10 = 55n
halfEven cents: 0,2,2,4,4,6,6,8,8,10 = 50n

Half-up always pushes ties the same way, so over many ties it drifts high. Half-even, also called banker's rounding, alternates and cancels out on average. Neither one is "correct." What matters is which one your contract, regulator or downstream system expects. Pick one, name it in code, and use it everywhere. Also note divRound(-25n, 10n) gives -3n, while Math.round(-2.5) gives -2.

4. The loan schedule: drift vs. the cents fix

Take $10,000 at 6% APR over 12 monthly payments. The standard formula gives a payment of $860.66 after rounding to cents.

Naive version: keep the balance as a float, round only when printing.

let bal = 10000, totalInt = 0, shownInt = 0, shownPrin = 0;
for (let k = 1; k <= 12; k++) {
  const interest = bal * 0.005;
  const prin = 860.66 - interest;
  bal -= prin;
  totalInt += interest;
  shownInt += Number(interest.toFixed(2));
  shownPrin += Number(prin.toFixed(2));
}

naive: interest column adds to 327.96 | total row shows 327.97
naive: principal column adds to 9999.96 | balance left 0.05

Three bugs in one table. Each printed row is rounded, but the running balance isn't, so the columns don't add up to the totals. And because the payment was rounded down from $860.6643, the loan never quite reaches zero.

Cents version: every amount is an integer number of cents. Interest is rounded once a month with a named rule, and the last payment absorbs whatever is left:

let b = 1000000n, payC = 86066n;
for (let k = 1; k <= 12; k++) {
  const interest = divRound(b * 600n, 12n * 10000n, 'halfEven'); // 6.00% = 600 bps
  const prin = k === 12 ? b : payC - interest;
  b -= prin;
  // record interest, prin, interest + prin, b
}

 1 $860.66 $50.00 $810.66 $9,189.34
 2 $860.66 $45.95 $814.71 $8,374.63
11 $860.66 $8.54 $852.12 $856.42
12 $860.70 $4.28 $856.42 $0.00
cents: interest $327.96 | principal $10,000.00 | balance $0.00

Every row now adds up, the columns match the totals, and the balance hits exactly zero. The 4-cent difference shows up where it belongs: a final payment of $860.70. That last-payment adjustment is common in real amortization schedules, and a printed table should show it rather than hide it.

Checklist

Store money as integer cents (or BigInt), never as float dollars.
Round at defined points, such as once per period, with a named rule (halfUp or halfEven).
Carry the rounded balance forward, so the table is self-consistent.
Let the final payment absorb the remainder.
Use Intl.NumberFormat only for display, and set roundingMode explicitly if it matters.

References

IEEE 754-2019, Standard for Floating-Point Arithmetic: https://standards.ieee.org/ieee/754/6210/
MDN, Number.prototype.toFixed(): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/toFixed
MDN, Intl.NumberFormat() constructor (roundingMode): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat/NumberFormat
MDN, Math.round(): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/round
MDN, Number.MAX_SAFE_INTEGER: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER

AI disclosure: this post was drafted with AI assistance. All code was run on Node 24, and the outputs shown are copied from that run.

Disclosure: I'm the maker of FINORA, a set of free browser-based finance calculators. No affiliate links, and this is about code, not financial advice. FINORA's loan calculator: https://finance.wooooju.com/en/calculator/personal-loan/

Testing Time-Zone Code Across DST Transitions: 23-Hour and 25-Hour Days in JavaScript (Temporal vs Date)

Nomad Wozo — Fri, 06 Nov 2026 02:17:06 +0000

Most JavaScript date bugs don't show up on ordinary weekdays. They show up on the two Sundays a year when a civil day is not 24 hours long. In the US, those Sundays are the spring-forward (clocks jump ahead) and fall-back (clocks repeat an hour). If your tests assume "one day == 86,400,000 ms," they will pass everywhere except the days that matter.

This article walks through those transitions for America/New_York in 2026, with every snippet run on Node.js v24.22.1 (TZ=America/New_York). typeof Temporal is undefined in this runtime, so the runnable examples use Date and Intl. Temporal's design goals are cited from the TC39 and MDN docs at the end — not from invented console output.

The 2026 US transitions (verified)

IANA rules for the US since 2007: spring forward on the second Sunday in March, fall back on the first Sunday in November, both at 02:00 local (Rule US ... Mar Sun>=8 / Nov Sun>=1). For America/New_York, zdump -v on this machine reports:

Sun Mar  8 06:59:59 2026 UT = Sun Mar  8 01:59:59 2026 EST  (UTC−05)
Sun Mar  8 07:00:00 2026 UT = Sun Mar  8 03:00:00 2026 EDT  (UTC−04)
Sun Nov  1 05:59:59 2026 UT = Sun Nov  1 01:59:59 2026 EDT  (UTC−04)
Sun Nov  1 06:00:00 2026 UT = Sun Nov  1 01:00:00 2026 EST  (UTC−05)

So 2026-03-08 is a 23-hour civil day (the 02:00–02:59 hour is skipped), and 2026-11-01 is a 25-hour civil day (01:00–01:59 occurs twice).

Intl agrees when you format the same UTC instants:

const fmt = new Intl.DateTimeFormat("en-US", {
  timeZone: "America/New_York",
  weekday: "short",
  year: "numeric",
  month: "short",
  day: "numeric",
  hour: "2-digit",
  minute: "2-digit",
  second: "2-digit",
  hourCycle: "h23",
  timeZoneName: "shortOffset",
});

console.log(fmt.format(new Date("2026-03-08T06:59:59Z")));
// Sun, Mar 8, 2026, 01:59:59 GMT-5
console.log(fmt.format(new Date("2026-03-08T07:00:00Z")));
// Sun, Mar 8, 2026, 03:00:00 GMT-4
console.log(fmt.format(new Date("2026-11-01T05:59:59Z")));
// Sun, Nov 1, 2026, 01:59:59 GMT-4
console.log(fmt.format(new Date("2026-11-01T06:00:00Z")));
// Sun, Nov 1, 2026, 01:00:00 GMT-5

Measure the civil day: midnight to midnight

A reliable check is the elapsed milliseconds between consecutive local midnights — not "add 24 hours to noon."

function localMidnight(y, m0, d) {
  return new Date(y, m0, d, 0, 0, 0, 0); // requires TZ=America/New_York
}

function hoursBetween(a, b) {
  return (b - a) / 3_600_000;
}

console.log(hoursBetween(localMidnight(2026, 2, 7), localMidnight(2026, 2, 8))); // 24
console.log(hoursBetween(localMidnight(2026, 2, 8), localMidnight(2026, 2, 9))); // 23
console.log(hoursBetween(localMidnight(2026, 10, 1), localMidnight(2026, 10, 2))); // 25

Actual printout:

Sun Mar 08 2026 → Mon Mar 09 2026: 82800000 ms = 23 hours
Sun Nov 01 2026 → Mon Nov 02 2026: 90000000 ms = 25 hours

If a scheduler, cron helper, or "daily digest" window hard-codes 24 * 60 * 60 * 1000, it will drift by one hour on each of these Sundays.

Adding 24 hours ≠ adding one calendar day

This is the classic footgun. Across the spring transition:

const start = new Date(2026, 2, 8, 1, 30, 0, 0); // Mar 8 01:30 EST
const plus24h = new Date(start.getTime() + 24 * 60 * 60 * 1000);
const plusCalDay = new Date(start);
plusCalDay.setDate(plusCalDay.getDate() + 1);

console.log(start.toString());
// Sun Mar 08 2026 01:30:00 GMT-0500 (Eastern Standard Time)
console.log(plus24h.toString());
// Mon Mar 09 2026 02:30:00 GMT-0400 (Eastern Daylight Time)
console.log(plusCalDay.toString());
// Mon Mar 09 2026 01:30:00 GMT-0400 (Eastern Daylight Time)
console.log(plus24h.getTime() === plusCalDay.getTime()); // false

Across the fall transition the same split appears the other way:

const start = new Date(2026, 10, 1, 0, 30, 0, 0); // Nov 1 00:30 EDT
const plus24h = new Date(start.getTime() + 86_400_000);
const plusCalDay = new Date(start);
plusCalDay.setDate(plusCalDay.getDate() + 1);

console.log(plus24h.toString());
// Sun Nov 01 2026 23:30:00 GMT-0500 (Eastern Standard Time)
console.log(plusCalDay.toString());
// Mon Nov 02 2026 00:30:00 GMT-0500 (Eastern Standard Time)

Rule of thumb: use calendar arithmetic (setDate / date-only fields) when you mean "tomorrow at the same wall time"; use a fixed millisecond duration when you mean "exactly 24 hours of elapsed time." They only coincide on 24-hour civil days.

Skipped local times (spring)

On 2026-03-08, local 02:30 never exists. MDN documents that Date follows Temporal's disambiguation: "compatible" behavior: a gap is resolved by moving forward by the gap length.

const skipped = new Date(2026, 2, 8, 2, 30, 0, 0);
console.log(skipped.toString());
// Sun Mar 08 2026 03:30:00 GMT-0400 (Eastern Daylight Time)
console.log(skipped.getHours(), skipped.getMinutes()); // 3 30

Neighbors confirm the gap:

01:59: Sun Mar 08 2026 01:59:00 GMT-0500 (Eastern Standard Time)
03:00: Sun Mar 08 2026 03:00:00 GMT-0400 (Eastern Daylight Time)

Any parser that accepts 2026-03-08T02:30 as a New York local time without a policy is lying to itself. Decide whether to reject, clamp forward, or clamp backward — and test it.

Ambiguous local times (fall)

On 2026-11-01, 01:30 occurs twice: once in EDT and once in EST. Date's compatible rule picks the earlier instant (still on daylight time):

const amb = new Date(2026, 10, 1, 1, 30, 0, 0);
console.log(amb.toString());
// Sun Nov 01 2026 01:30:00 GMT-0400 (Eastern Daylight Time)
console.log(amb.getTimezoneOffset()); // 240  (EDT = UTC−4)

Stepping through UTC makes the repeated hour visible:

2026-11-01T05:30:00.000Z → Sun Nov 01 2026 01:30:00 GMT-0400 (EDT)
2026-11-01T06:00:00.000Z → Sun Nov 01 2026 01:00:00 GMT-0500 (EST)
2026-11-01T06:30:00.000Z → Sun Nov 01 2026 01:30:00 GMT-0500 (EST)

If you store "local wall time" without an offset or a fold bit, you cannot round-trip the second 01:30.

A small test table you can paste into CI

These six checks all passed on the same Node run (TZ=America/New_York):

Check	Expected	Observed
Mar 7 length	24h	24h
Mar 8 length	23h	23h
Nov 1 length	25h	25h
`new Date(2026,2,8,2,30)`	maps to 03:30 EDT	03:30 EDT
`new Date(2026,10,1,1,30)`	earlier (EDT, offset 240)	offset 240
`+24h` vs `setDate(+1)` on Mar 8 01:30	different instants	different

Keep the zone explicit (TZ=… in the process, or always format with timeZone: "America/New_York"). Host-local tests on a machine in Asia/Seoul or UTC will never exercise US DST gaps.

Where Temporal fits (and why it isn't in these run outputs)

On this Node v24.22.1 binary, typeof Temporal === "undefined". No Temporal polyfill was available offline, so this article does not invent Temporal console output.

What Temporal is designed to fix is exactly the confusion above. Per the TC39 Temporal proposal and MDN's Temporal overview:

Temporal.Instant is a unique point on the timeline (like a better epoch nanosecond stamp).
Temporal.PlainDateTime is a wall-clock date/time without a zone — the "read it off a calendar" value.
Temporal.ZonedDateTime pairs calendar fields with a named zone and exposes hoursInDay, startOfDay(), and explicit disambiguation when a local time is skipped or repeated.

In other words: Instant answers "when in absolute time?"; Plain* answers "what does the clock/calendar say?"; ZonedDateTime is the bridge that knows DST. Legacy Date tries to wear both hats at once, which is why + 86400000 and "add one day" silently diverge.

Until Temporal is available in your runtime, you can still write correct tests with Date + Intl — as long as you pin the zone, measure civil-day length, and assert both the gap and the fold.

Practical checklist

Pick real transition dates from IANA/zdump for the zones you support (here: 2026-03-08 and 2026-11-01 in New York).
Assert civil-day length is 23h / 25h across those midnights.
Assert + 24h and calendar + 1 day diverge.
Assert skipped times resolve the way your product promises (Date's default: jump forward).
Assert ambiguous times pick a documented fold (Date's default: earlier / DST side).
Prefer storing UTC instants or offset-aware strings; treat bare local times as incomplete.

Sources

MDN: Date (gap/fold = Temporal compatible)
MDN: Intl.DateTimeFormat
MDN: Temporal
TC39 Temporal proposal
IANA: How to Read the tz Database (US Mar Sun>=8 / Nov Sun>=1 rules)

I built a small two-city time zone converter, WorldTimeSync: https://time.wooooju.com/en/

Your setInterval countdown is lying to you in background tabs

Nomad Wozo — Thu, 29 Oct 2026 10:08:06 +0000

I built a little browser timer as a side project, and the first bug report I gave myself was "the countdown is wrong when I come back to the tab." Classic.

Here's the thing: browsers ration timers on hidden pages to save battery. Chrome documents three stages (source):

Minimal throttling: page is visible, or made sound in the last 30s. Timers run roughly on time.
Throttling: page is hidden. Timers get checked about once per second.
Intensive throttling (Chrome 88+): hidden for 5+ minutes, silent for 30+ seconds, and the timer chain count is 5 or more. Now timers get checked once per minute.

Firefox has its own rules too. MDN notes a 1s minimum in inactive desktop tabs and up to 15 minutes on Firefox for Android (MDN).

So if your countdown does this:

let remaining = 25 * 60;
setInterval(() => {
  remaining -= 1;      // assumes exactly 1s passed. it didn't.
  render(remaining);
}, 1000);

...it drifts the moment the tab goes into the background.

Store the deadline, not the count

const endsAt = Date.now() + 25 * 60 * 1000;

function tick() {
  const remainingMs = Math.max(0, endsAt - Date.now());
  render(Math.ceil(remainingMs / 1000));
  if (remainingMs === 0) finish();
}

setInterval(tick, 250);
document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'visible') tick(); // snap to the truth on return
});

Now the number is always right when the user looks at it. Persist endsAt to localStorage and it even survives a reload. (Trade-off: Date.now() follows the device clock, so if someone changes their clock, the countdown moves with it.)

What this does NOT fix

A correct number on return isn't the same as a sound that plays on time while the tab is hidden or the phone is asleep. Things that help, honestly listed:

Keep the page visible.
The Screen Wake Lock API keeps the screen on, but only while the page is visible, and the system can release it (low battery, power saver). HTTPS only.
Tell users plainly: don't use a web timer as a safety-critical alarm.

That last one felt weird to put in my own UI, but I'd rather be upfront than have someone miss something important.

If you want to poke at the result, it's moment.: Pomodoro, intervals, a lap stopwatch and D-Day counters, no sign-up, and everything stays in your browser. Happy to hear how you handle this in your own apps.

Why counting business days is harder than it looks

Nomad Wozo — Fri, 23 Oct 2026 09:11:44 +0000

"Delivery in 10 business days." Sounds simple, right up until two people land on two different dates. Here are the traps I keep running into, plus a small JavaScript algorithm that doesn't drift by a day.

1. Does the start date count?

It's Monday and the deadline is "5 business days". Is that this Friday or next Monday? It depends on the convention:

Exclusive (the start date doesn't count): Monday + 5 business days = next Monday.
Inclusive (the start date is day 1): the 5th business day is Friday.

Excel uses both. WORKDAY returns the date a given number of working days after the start date, so the start date itself isn't counted. NETWORKDAYS counts whole working days including both ends. So NETWORKDAYS(start, WORKDAY(start, 5)) returns 6 when the start is a workday. Agree on the convention before you argue about the deadline.

2. Weekends aren't always Saturday and Sunday

A few examples:

Saudi Arabia: Friday–Saturday
Israel (Friday–Saturday for most offices; Sunday is a workday)
Retail, healthcare and shift teams often have a single day off, or a rotating one

Excel handles this with WORKDAY.INTL and NETWORKDAYS.INTL. The weekend argument takes a number (1 = Saturday–Sunday, 7 = Friday–Saturday, 11 = Sunday only) or a 7-character string that starts on Monday, where 1 means day off: "0000011" is Saturday–Sunday, "0000001" is Sunday only.

If your code hard-codes [0, 6], it's wrong for a lot of people.

3. Holidays move

Observed holidays. For US federal employees, a holiday that falls on a Saturday is observed on the Friday before, and one that falls on a Sunday is observed on the Monday after.
Substitute holidays. The UK and South Korea, among others, add a substitute day off when certain holidays land on a weekend.
Local holidays. National, state and city holidays stack. There is no single "holiday list" for a country that works for everyone.

The right holiday list is the one that applies to that team, in that place, this year.

4. Exceptions: a day off that becomes a workday

Make-up days, inventory Saturdays, on-call weekends... A usable model needs both extra days off and exceptional working days, and the exceptions have to override the weekly day off.

5. Time zones break dates

In JavaScript, new Date("2026-03-02") is parsed as midnight UTC. Anywhere west of UTC (the Americas, for example), getDay() and getDate() give you Sunday the 1st instead of Monday the 2nd. Parse date-only strings yourself and stay in UTC from start to finish.

An algorithm that handles all of the above

const parse = s => { const [y, m, d] = s.split("-").map(Number); return new Date(Date.UTC(y, m - 1, d)); };
const fmt = d => d.toISOString().slice(0, 10);

function isWorkday(date, { weekendDays = [0, 6], holidays = [], extraWorkdays = [] } = {}) {
  const key = fmt(date);
  if (extraWorkdays.includes(key)) return true;   // an exception beats the weekly day off
  if (holidays.includes(key)) return false;
  return !weekendDays.includes(date.getUTCDay()); // 0 = Sunday
}

// n > 0 moves forward, n < 0 moves backward.
// inclusive: the start date counts as day 1 if it is a workday.
function addWorkdays(start, n, { inclusive = false, ...cal } = {}) {
  const step = Math.sign(n) || 1;
  let left = Math.abs(n);
  const d = parse(start);
  if (left === 0) return fmt(d);
  if (inclusive && isWorkday(d, cal)) left--;
  while (left > 0) {
    d.setUTCDate(d.getUTCDate() + step);
    if (isWorkday(d, cal)) left--;
  }
  return fmt(d);
}

const cal = { holidays: ["2026-11-20"] };
addWorkdays("2026-11-16", 5, cal);                      // "2026-11-24"
addWorkdays("2026-11-16", 5, { ...cal, inclusive: true }); // "2026-11-23"
addWorkdays("2026-03-02", 5);                           // "2026-03-09"
addWorkdays("2026-03-02", 5, { inclusive: true });      // "2026-03-06"

It walks one calendar day at a time instead of doing clever math with / 7. For deadlines measured in days or weeks, that's plenty fast, and it's much easier to explain why a given date was skipped.

In TypeScript, I'd type the calendar as { weekendDays: number[]; holidays: string[]; extraWorkdays: string[] } and use Sets if the lists get long.

Checklist

Write down whether the start date counts.
Make the weekend configurable.
Let the user supply holidays; don't pretend one list fits a whole country.
Support exceptional working days.
Parse date-only strings in UTC.
Show which days were counted and which were skipped.

How does your team count "business days"? I'd love to hear the edge cases I missed.

Disclosure: I build WorkdayMap, a free business-day calculator that applies these rules and shows every counted and skipped day.

Why 6% isn't 6%: APY vs. nominal rate in JavaScript (and the double-compounding bug)

Nomad Wozo — Thu, 22 Oct 2026 02:43:22 +0000

I build small finance calculators that run entirely in the browser. The sneakiest bug in this kind of code isn't floating point. It's feeding the wrong kind of rate into the formula.

Here's the short version, then the code.

Two rates, one label

A savings account can quote two numbers:

Nominal annual rate (US deposit rules let banks call it the "annual percentage rate"): the yearly rate before compounding.
APY (annual percentage yield): what you actually earn in a year once compounding is included.

US Regulation DD defines the interest rate as "the annual rate of interest paid on an account which does not reflect compounding" and the APY as the rate "based on the interest rate and the frequency of compounding for a 365-day period" (12 CFR 1030.2). When a deposit ad states a rate, it has to state it as an APY, and the plain interest rate can't be shown more prominently (12 CFR 1030.8).

So if your calculator compounds monthly, it wants the nominal rate. Users, meanwhile, mostly have the APY, because that's what's on the bank's website.

The two functions you need

// nominal annual rate -> APY, compounded n times per year
const apy = (rate, n) => (1 + rate / n) ** n - 1;

// APY -> nominal annual rate for n compounding periods
const nominalFromApy = (y, n = 12) => n * ((1 + y) ** (1 / n) - 1);

const balance = (principal, rate, years, n = 12) =>
  principal * (1 + rate / n) ** (n * years);

How much does compounding frequency matter?

Same 6% nominal rate, $10,000, 30 years, nothing added:

for (const [name, n] of [["annually", 1], ["quarterly", 4], ["monthly", 12], ["daily", 365]]) {
  console.log(name, apy(0.06, n), balance(10_000, 0.06, 30, n));
}

Compounding	APY	After 30 years
Annually	6.0000%	$57,434.91
Quarterly	6.1364%	$59,693.23
Monthly	6.1678%	$60,225.75
Daily	6.1831%	$60,487.53
Continuous (`Math.exp(0.06) - 1\`)	6.1837%	n/a

Annual to monthly is the big jump. Monthly to daily barely moves the needle, and continuous compounding is the ceiling. If you're agonizing over daily vs. monthly in your code, you can relax a bit.

The double-compounding bug

A user sees "6.00% APY," types 6 into your monthly-compounding calculator, and you happily compound it again:

const advertisedApy = 0.06;

balance(10_000, advertisedApy, 10);                 // 18193.97  (too high)
balance(10_000, nominalFromApy(advertisedApy), 10); // 17908.48  (matches a true 6% APY)

That's $285.49 of imaginary money after 10 years on $10,000. Not huge, but it's the kind of error that makes someone distrust every other number on the page. And it grows with the rate and the time horizon.

nominalFromApy(0.06)\ is about 5.8411%. A few more conversions, monthly compounding:

Advertised APY	Nominal rate to enter
3.5%	3.4451%
4.0%	3.9285%
5.0%	4.8889%
6.0%	5.8411%

Things I'd do in any calculator UI

Label the input with the rate type. "Annual interest rate (nominal, compounded monthly)" is ugly but honest. A small "Have an APY? Convert it" helper is nicer.
Be explicit about rounding. If your rate field steps by 0.1, a 6% APY becomes 5.8% (APY 5.957%), not 5.8411%. Close enough for planning, but say so.
Round only for display. Keep full precision through the loop and round to cents at the end:

   const roundCents = (x) => Math.round((x + Number.EPSILON) * 100) / 100;
   roundCents(balance(10_000, 0.06, 1)); // 10616.78

(And yes, 0.1 + 0.2\ is still 0.30000000000000004\. For a planning calculator, floats plus display rounding are fine. For anything that moves real money, use integer cents or a decimal library.)

Show the formula. Users catch rate-type mistakes much faster when they can see (1 + r/12)^12 − 1\ on the page.
Don't call a loan APR an APY cousin. Loan APR follows separate disclosure rules and can bake in fees. Everything above is about deposit interest only.

Why I keep this math client-side

None of this needs a server. It's a few exponentials, so the whole calculation can run in the browser and the user's numbers never leave their device. For financial inputs, that feels like the right default, and it makes the app work offline too.

Disclosure: I'm the maker of FINORA, a set of free browser-based financial calculators (no sign-up). Its compound interest calculator takes a nominal rate and compounds monthly, which is where the 0.1-step note above comes from: https://finance.wooooju.com/en/calculator/compound-interest/ . No affiliate links in this post. This is math, not financial advice.