DEV Community: zhihu wu

Your String Length Is a Lie: Four Unicode Traps in Everyday Code

zhihu wu — Sat, 24 Oct 2026 13:01:57 +0000

Every character counter you have ever written is wrong for at least one of your users. Here are the four Unicode traps I keep finding in code reviews — each one verified in Node, not recalled from a blog post.

1. `.length` counts UTF-16 code units, not characters

"\u{1F44D}".length                    // 2  (one thumbs up)
"\u{1F1E8}\u{1F1F3}".length           // 4  (one flag)
"\u{1F468}\u200D\u{1F469}\u200D\u{1F467}\u200D\u{1F466}".length  // 11 (one family)

Code points are closer: [...str].length gives 7 for that family. But only grapheme clusters give the real answer:

[...new Intl.Segmenter("en", {granularity: "grapheme"}).segment(str)].length  // 1

The dangerous part is slicing. str.substring(0, 1) on a thumbs up returns a lone high surrogate. Encode that and you get 3 bytes of replacement character — no exception, no warning, just corrupted data in your database.

2. "é" is sometimes two characters

const nfc = "é".normalize("NFC");   // 1 unit, 2 bytes
const nfd = "é".normalize("NFD");   // 2 units, 3 bytes
nfc === nfd;                        // false

Identical pixels, different strings. new Map([[nfd, 1]]).has(nfc) is false, so dedupe, rate-limit keys, email lookups and "already exists" checks quietly miss. macOS filenames arrive decomposed, so this is not a theoretical case. Normalize to NFC at the boundary, before hashing or comparing.

3. Invisible characters survive `trim()`

" \u200B ".trim().length is 1 — a zero-width space is not whitespace in JavaScript, and /\s/.test("\u200B") is false. A non-breaking space, by contrast, is stripped. So text pasted from a browser can look perfectly clean and still not match.

Markdown is where it hurts most. I tested rendered output in a GFM previewer: a "blank" line containing only U+00A0 does not split paragraphs, and a line where the space before # is U+00A0 never becomes a heading — it renders as <p> # Title</p>.

4. Bytes are a third number

The same family emoji is 11 UTF-16 units, 7 code points, 1 grapheme and 25 UTF-8 bytes. Column lengths, index key limits (utf8mb4 reserves 4 bytes per character), and base64 payloads all run on bytes, so a 768-character field is not a 768-byte field.

Rule of thumb: units for strings, code points for iteration, graphemes for UI, bytes for storage.

When I need to find which of these is biting me, I dump the string into a character-level inspector — I use Unicode Inspector, which runs entirely in the browser and shows the code point, UTF-16 units, UTF-8 bytes and entity for every character, plus filters for invisible ones. Paste a failing value in, find the U+200B you could not see, done.

Your Amortization Loop Never Reaches Zero: 4 Bugs in Loan Math Code

zhihu wu — Mon, 19 Oct 2026 13:02:41 +0000

If you've ever generated an amortization schedule by hand, you've probably hit this: you loop 360 times and the balance lands on... -$3.07. Or +$0.84. Never exactly zero.

Here are four bugs I keep running into, with numbers you can check yourself.

1. The loop's last step is a lie

$300,000 at 7% over 360 months. The exact payment is 1,995.9074..., which you round to 1,995.91. Run balance = balance + balance*r - payment 360 times and the balance ends at -$3.07 - you overpaid by three dollars because you rounded the payment up. Round down and you finish with a small balance the borrower still owes.

Switching to integer cents doesn't fix it; it just relocates the error (same loan, same 360 iterations: -355 cents).

The fix is to stop trusting the last iteration. After payment 359 the balance is $1,981.28, so the final payment must be balance * (1 + r) = $1,992.84. Lenders do exactly this: a fixed payment for every month except the last.

2. Accruing interest after subtracting the payment

balance = (balance - payment) * (1 + rate);  // wrong
balance = balance * (1 + rate) - payment;    // right

Both look reasonable. They differ by one period of interest on the payment itself, and the first version "pays off" in 354 payments instead of 360 while reporting $406,552 of total interest instead of $418,527 - $11,975 short. Nobody notices, because the schedule still ends near zero.

3. setMonth() drifts

A schedule assumes "the same day each month". JavaScript disagrees:

new Date(2026, 0, 31).setMonth(1) // -> Mar 3, not Feb 28

A 30-year schedule built month-by-month slides forward every time it crosses a short month. The dates in the table look plausible; they're just wrong by a few days that keep accumulating.

4. "Extra payment" is not principal by default

Many servicers apply extra money to your next installment, which only advances the due date. The loan still runs the full term and total interest is unchanged. You have to mark it principal-only, then verify on the next statement that the principal balance actually dropped.

Get it right and the payoff is real: $100/month extra on that $300k loan clears it in 310 payments - about 4.2 years early, roughly $69,300 of interest saved.

I keep a free loan calculator open for checking these by hand - it runs entirely in the browser, shows the full schedule and the year-end summaries, which is how I caught the rounding bug in my own script.

Your Placeholder Text Is Lying to You: 4 Layout Bugs Lorem Ipsum Hides

zhihu wu — Fri, 16 Oct 2026 13:04:23 +0000

Every mockup I reviewed this year used lorem ipsum. Several of those layouts broke in production - not because the design was bad, but because the placeholder text was too friendly.

Here is what lorem ipsum optimizes for, and what it quietly hides.

1. It has no long, unbreakable strings

Lorem ipsum words are short, lowercase, and separated by spaces. Real content contains things the browser cannot hyphenate: a 90-character signed URL, an address like firstname.lastname@international-partners.example.com, an API token, a German compound noun. Those are what overflow a flex row - flex: 1 will not shrink below the content's min-content width unless you also set min-width: 0 (or overflow-wrap: anywhere). You will never see that bug in a lorem ipsum mock. Paste one long token into your design before you call it done.

2. It never expands

German text runs roughly 30% longer than English, Finnish invents longer compounds, and CJK wraps between any two characters instead of at spaces. A button label that fits at 320px in English can overflow in two languages. Test with the longest realistic translation - or at minimum add 30% to every label and re-check the tight rows.

3. It hides truncation and empty states

Lorem ipsum paragraphs are all the same length, so list rows never collapse, cards never hit their one-line truncation, and -webkit-line-clamp never gets exercised. Real data puts a one-word title and a 300-word title in the same list. Feed the layout a deliberately awkward set of strings - empty string, a single character, one 200-character sentence - and look at each row again.

4. It hides the labels

Placeholder copy tends to be descriptive nouns. Real UI copy is verbs and consequences: "Delete workspace", not "Workspace deletion". If a screen only reads correctly with lorem ipsum in it, the placeholder is doing layout work that the layout should be doing.

When lorem ipsum is the right call

Before the copy exists at all - early explorations where you are deciding spacing, hierarchy, and density. Once the layout is settled, swap in realistic strings. When I need filler fast I use a lorem ipsum generator: it runs entirely in the browser (nothing uploaded, no signup), you choose the paragraph and sentence counts, and the output pastes straight into test fixtures.

The rule I keep coming back to: if your placeholder text would pass a type checker, it is not testing anything.

Four Ways a Git Diff Lies to You (and How to Catch Each)

zhihu wu — Wed, 14 Oct 2026 13:02:46 +0000

Every code review is a promise: this is what changed. Most days the tooling keeps that promise. Sometimes it quietly breaks it, and the break is subtle enough to survive approval.

Four diff blind spots I keep running into — each one makes a change set look bigger, smaller, or simply different than reality.

1. Two dots and three dots are not the same comparison

git diff main..feature     # tip vs tip
git diff main...feature    # merge-base vs tip

main..feature compares the two branch tips directly. main...feature (three dots) compares from the merge base — the last commit both branches share. GitHub pull requests show you the three-dot view.

So if you review locally with two dots after main has moved on, you see every commit merged into main since the branch split — none of which your PR touched. A 12-line PR suddenly reads like 400 lines. When a change count looks absurd, check the dot count before you blame your own branch.

2. Plain `git diff` only shows unstaged changes

git diff compares the working tree against the index. Run git add and those edits drop out of that comparison entirely — the diff goes quiet while your changes are still there. Use git diff --cached for staged work, or git diff HEAD to see both at once.

Untracked files are a harder case: brand-new files never appear in any git diff output. Only git status lists them.

3. A moved file arrives as a delete + add

Rename detection is a heuristic, not a fact. Move a file with plain mv and the diff shows a 300-line deletion plus a 300-line addition — so a reviewer's eye slides past the four lines you actually edited.

git diff -M --stat
someFile.ts | 2 +-
similarity index 98%

-M turns rename detection on explicitly (tune with -M40% if a heavily edited move is missed). --stat gives you the one-line summary that makes the real edit visible again.

4. That "whole file changed" diff is formatting, not data

Minified vs pretty JSON, CRLF vs LF, reordered keys: a one-field change to a 200-line API response renders as the entire file. Normalize both sides before comparing — jq -S for key order, a formatter for whitespace, dos2unix for line endings — and then everything left in the diff is real.

And when the two versions don't live in a repo at all (a log viewer, a chat message, a CMS), there's no file to run diff on. I paste both sides into CodeToolbox's diff checker — it runs in the browser, uploads nothing, and shows the added/removed lines plus a summary count before you scroll.

Blind spot 1 is the expensive one: the extra lines are real commits, just not yours. Check the dot count first.

Your Cron Job Runs at the Wrong Time (or Twice): Four Traps in Five Fields

zhihu wu — Sun, 11 Oct 2026 13:01:44 +0000

Cron is 50 years old, has five fields, and still owns a special place in every on-call rotation. Nearly every "why did this run at 3am" ticket traces back to one of four things.

1. Two restricted date fields mean OR, not AND

0 9 1 * 1 reads like "9:00 on the 1st, if it's a Monday." Cron reads it as "9:00 on the 1st or any Monday." When both day-of-month and day-of-week are restricted, you get a union — so a monthly job quietly also runs four Mondays a month.

Fix: keep one field as * and filter inside the command.

# Mondays only
0 9 * * 1 /app/monthly.sh

If you specifically need "the Monday that falls in the first week," schedule every Monday and let the script check date +%d.

2. `*/2` in day-of-month doesn't mean "every two days"

Steps in the day-of-month field start at 1, so 0 3 */2 * * fires on 1, 3, 5 … 31 and then resets. The gap across the month boundary is one day after a 31-day month and two days after a 30-day month. Any job doing interval arithmetic — log rotation, rolling windows, invoice cutoffs — drifts or double-fires.

Fix: run daily and store the last-run date in a file, or use a scheduler with real interval semantics.

3. Cron uses the server's timezone, and containers are UTC

0 0 * * * means midnight on the host. Inside a container that is midnight UTC: 8am in Beijing, 5pm the previous day in California. GitHub Actions cron is always UTC regardless of what your repo implies.

Fix: be explicit. CRON_TZ=America/New_York (cronie), or set TZ on the container, or keep everything UTC on purpose and convert in the application. All three beat "we assume it's local time."

4. An unescaped `%` eats the rest of your command

In a crontab file, % is not a literal character — it terminates the command and everything after it becomes the job's stdin:

0 4 * * * /usr/bin/backup.sh --name daily-%Y%m%d

That runs backup.sh --name daily- with Y%m%d piped into it, and still exits 0. Escape each percent sign: daily-\%Y\%m\%d. GitHub Actions and Kubernetes treat % literally, so this trap is crontab-only — which makes it harder to catch when you move a workflow between the two.

How I check a schedule before it ships

I paste the expression into a visual builder that renders the next five run times in plain English — CodeToolbox's cron generator does it locally in the browser with no signup, and shows the day-of-month/day-of-week OR behaviour explicitly — then I compare those timestamps against my own calendar before the expression reaches a server. Five run times surface all four traps above.

What's the worst cron bug you've had to debug?

UUIDs That Look Identical Aren't: The Case, Braces, and Hyphen Trap

zhihu wu — Fri, 09 Oct 2026 13:02:36 +0000

The bug that makes no sense

A row exists. The API returns its ID. You paste that ID into a query and get… nothing. You look at both strings side by side. They are the same. Except they are not, because "the same" for a UUID string means byte-for-byte identical, and four sneaky formatting differences break that all the time.

1. Case

.NET's Guid.ToString() returns lowercase. SQL Server hands back uppercase. Postgres normalizes to lowercase, and an API gateway somewhere in the middle may have done whatever it wanted. In every case-sensitive comparison — a JS ===, a SQL WHERE id = '...', a Redis key — "ABC..." and "abc..." are different values. Same UUID, failed lookup.

2. Hyphens

Canonical form is 8-4-4-4-12, 36 characters. But UUIDs travel through places that strip punctuation: URL slugs, log parsers, spreadsheet columns, that one time someone hit sed 's/-//g'. The 32-char hex form is a legitimate representation of the same value and an instant mismatch against a stored canonical string.

3. Braces and parentheses

C# and PowerShell are happy to hand you {550e8400-e29b-41d4-a716-446655440000} or (550e8400-...). If that string is what went into your DB or your cache key, your canonical-form lookups will never hit.

4. Hex vs bytes

MySQL's UUID_TO_BIN() stores 16 raw bytes for indexing efficiency — correct and fast. It also means a plain string comparison against that column returns nothing at all, and BIN_TO_UUID() has to be in both your SELECT and your WHERE, or you are comparing apples to BLOBs.

The fix: normalize at the boundary

The rule I now follow: parse on input, format on output, never compare raw strings from two different sources.

Normalize to lowercase, hyphen-free hex before any equality check or cache key. One toLowerCase().replaceAll('-', '') kills cases 1–3.
Parse, don't regex, when you can: UUID.fromString() in Java, uuid.UUID() in Python, uuid.Parse() in Go all accept the mixed forms and reject genuinely malformed input — a validation bonus you don't get from a loose pattern.
Validate with the version/variant bits in mind if you care about v4 vs v7, since a regex that only checks the 8-4-4-4-12 shape happily accepts a v7 ID where you expected v4 (and vice versa).
Log the raw form when debugging. Half of these bugs are invisible because whatever printed the ID for you already normalized it.

When I need a handful of IDs in a known-good canonical form to test a normalization path — or to check what my parser does with the uppercase, braced, hyphen-less variants — I generate them in a free in-browser UUID generator that runs entirely on the client, no upload, no signup. It does bulk output up to 100 at a time and the uppercase/lowercase toggle is handy for exactly the comparison bug above.

None of this is exotic. It is just the reason two strings that "look identical" quietly fail the only test that matters.

Your Base64 Decoding Failed Because of Whitespace (and 3 Other Silent Traps)

zhihu wu — Tue, 06 Oct 2026 13:03:03 +0000

You paste a Base64 string into a decoder, and it throws InvalidCharacterError or returns garbage. Nine times out of ten the alphabet is fine — it's invisible whitespace, padding, or the URL-safe variant that broke it.

Here are the four traps I hit most often, and how to spot each one in seconds.

1. Line breaks (the MIME 76-column wrap)

Email-era encoders still wrap output at 76 characters with \r\n. Python's base64.encodebytes() does this, and so do PEM/JWKS files. atob() in the browser refuses any whitespace, so a string that looks perfect silently fails. Strip all whitespace before decoding, and prefer base64.b64encode() over encodebytes() when you control the encoder.

2. Missing or excess padding

= pads the final group to a multiple of 4 characters. YWJjZA (6 chars) and YWJjZA== are the same bytes, but many strict decoders reject the unpadded form. Some SDKs strip padding; others require it. If a decoder fails, add = until length % 4 == 0.

3. base64url vs base64

JWTs, URL query params, and filenames use the URL-safe alphabet: - and _ replace + and /, and padding is usually dropped. Feed a JWT segment straight into a standard decoder and it breaks. In Python: base64.urlsafe_b64decode(s + "=" * (-len(s) % 4)). In JS, do the character swap yourself — replace(/-/g, '+').replace(/_/g, '/') — before calling atob.

4. Encoding text is not encoding bytes

atob() returns a binary string, so UTF-8 text comes back as mojibake. Decode to bytes first, then to text: new TextDecoder().decode(Uint8Array.from(atob(s), c => c.charCodeAt(0))), or base64.b64decode(s).decode('utf-8') in Python.

The five-second check

Before you debug your code, look at the string itself: any whitespace, any - or _, does the length divide by 4? That diagnoses most "corrupted Base64" bugs without touching the source.

When I need to eyeball a payload — checking padding, spotting a base64url segment inside a JWT, or confirming a decode round-trips my UTF-8 — I use CodeToolbox's Base64 encoder/decoder. It runs entirely in the browser (nothing is uploaded), accepts both alphabets, and shows character counts so you can see the padding at a glance.

Your JWT Works Locally but 401s in Production - Check These 5 Things First

zhihu wu — Sun, 04 Oct 2026 13:02:41 +0000

You paste the token your API just issued into a decoder. The header parses, the payload parses, everything looks right - and the request still comes back 401 Unauthorized.

Signature bugs get all the attention, but in practice most "valid-looking token rejected" incidents are one of five boring mismatches. Decode the token first, then walk this list in order.

1. Clock skew between two servers

A token is minted with iat and validated against nbf and exp. If the machine that issued it is a few seconds behind the machine validating it, a token created "just now" can look like it is not valid yet. Most libraries default to 30-60 seconds of leeway - if someone tightened that, put it back. The tell: the token decodes, exp is clearly in the future, and the failure is intermittent.

2. The audience or issuer doesn't match

aud and iss are the two claims people skip. Your auth service may issue tokens for api.example.com while the service you are calling is configured to accept *.internal. Paste the token, read aud and iss, and compare them character by character with the validator's config. It is almost always one environment variable.

3. Key rotation and the kid header

When a provider rotates signing keys, the token's header carries a kid (key id) saying which key signed it. If your validator only loads the old key, every freshly issued token fails while older ones still work - or the exact reverse. Compare the kid in the header with the keys your verifier actually has loaded.

4. The algorithm is mis-declared

A token signed with RS256 but handed to a service pinned to HS256 fails even though the payload is perfect. Worse: if the service reads alg from the token itself, an "alg": "none" token lets an attacker strip the signature entirely. Pin the accepted algorithm server-side and never trust the header's alg field.

5. You are testing the wrong copy of the token

Embarrassingly common. The token in your clipboard came from a truncated log line, an earlier request, or a different user's session. Decode the exact string you are sending, not the one you think you are sending.

The point is that decoding is free and instant, and it removes guesswork. I use CodeToolbox's JWT Decoder - it runs entirely in the browser with atob and JSON.parse, so the token never leaves your machine, which matters because a JWT is a bearer credential. It renders exp/iat/nbf as readable dates and flags unsecured alg: none tokens.

Decode anywhere; verify the signature server-side with a real library.

Your Regex Works in Python but Breaks in JavaScript - Here's Why

zhihu wu — Thu, 01 Oct 2026 13:01:41 +0000

You write a pattern, it passes your tests in a Python service, and then the same string in a Node script returns null. Regular expressions are "the same everywhere" right up until they aren't — and the differences are exactly the ones that cost you an afternoon.

Here are the four that bite hardest.

1. Named group syntax is not shared

Python uses (?P<year>\d{4}). JavaScript uses (?<year>\d{4}). Paste the Python version into a .js file and you get a SyntaxError: Invalid regular expression with no line number pointing at the offending group.

2. `\d` and `\w` disagree about Unicode

In Python 3, str patterns are Unicode-aware by default: re.findall(r'\w+', 'café') returns ['café']. In JavaScript, \w is ASCII-only — even with the u flag — so 'café'.match(/\w+/g) stops at caf. If you need Unicode categories in JS, you must spell it out with property escapes: \p{L}, \p{Nd}. Python spells them \w and \d and calls it a day.

Rules extracted from a mixed-language codebase break in whichever language you didn't test.

3. Lookbehind: fixed width vs variable length

Python's re requires lookbehinds to be fixed width. (?<=foo|foobar) raises error: look-behind requires fixed-width pattern. JavaScript's engine accepts variable-length lookbehinds — and Safari only shipped them in 16.4, so a pattern that passes in Chrome can throw on an older iOS client.

4. `match()` does not mean the same thing

re.match() anchors at position zero; re.search() doesn't. JavaScript's String.prototype.match() behaves like Python's search, not its match. That single-word difference is behind a lot of "but it matched the whole string in my test!" confusion. If you need Python's strict behaviour in JS, anchor both ends explicitly — ^...$ — because JavaScript has no fullmatch equivalent.

The fix: test the pattern, not the language

None of these are hard once you see them — the trick is seeing them in seconds instead of in production. I keep a regex tester open in a browser tab while writing patterns: paste the pattern and a sample of the real input, watch the matches highlight as you type, and check the capture groups panel before the pattern ever lands in code. It uses the browser's own engine, so what you see is exactly what JavaScript will do with it — no round-trip to a server, and nothing in your test string leaves the machine (which matters when the sample is a log line full of tokens).

The PyPI-style patterns I copy into JS now get a two-second sanity check first. That's the whole habit, and it has saved me more debugs than any linter.

I use CodeToolbox's Regex Tester — it is free, runs entirely client-side, and has preset patterns for email, URL, IPv4 and dates that you can bend into shape instead of starting from an empty box.

camelCase vs snake_case: The Naming Bug That Survives Code Review

zhihu wu — Tue, 29 Sep 2026 13:01:41 +0000

Every team eventually ships a payload like this:

{
  "userId": 42,
  "created_at": "2026-09-01T10:00:00Z",
  "IsActive": true
}

Three fields, three conventions. It passes code review because every line looks fine in isolation. It breaks in production because every consumer now has to special-case field names.

The failure mode is silence

The expensive version of this bug does not throw. Your backend is written in Python with snake_case columns, the frontend is TypeScript and sends camelCase, and the serializer you assumed existed... does not. So userId arrives, nothing reads it, and the handler writes user_id: null. No 422, no stack trace — just rows that look wrong three weeks later.

Both ends were internally consistent. That is what makes it survive review: naming style is a contract between two codebases, and nothing in either repo checks the contract.

Where the two styles come from

It is not a style disagreement, it is two ecosystems meeting:

SQL, Python and Ruby idioms use snake_case: user_id, created_at.
JavaScript, Java and C# idioms use camelCase / PascalCase: userId, createdAt.

So the boundary belongs to one explicit layer — a serializer, a DTO, a mapper. When that layer is missing, ORM column names leak straight into your public JSON, and the API's naming becomes whatever the database happens to use.

Round-trip it, don't eyeball it

Pick one convention per boundary and assert it in a test. Cheapest version: serialize a sample object, convert each key, and compare. Or snapshot one real response body in CI, so an accidental created_at shows up as a diff instead of a support ticket.

Two traps that break naive converters:

Acronyms split inconsistently. parseHTTPResponse becomes parse_httpresponse or parse_http_response depending on the rule. Round-trip both directions in a test before trusting a bulk rename.
Filesystem casing. Renaming UserService.ts to userservice.ts builds fine on a case-insensitive macOS volume and fails on a case-sensitive Linux CI. Same root cause: casing treated as decoration instead of part of the name.

The practical rule

One canonical spelling per layer — user_id in Postgres, userId in JSON, USER_ID in the env file — and no variants in between. When I need to flip a list of identifiers between conventions (column names → JSON keys, or the reverse before a migration), I use the Case Converter at codetoolbox.pro — paste the whole list once and it returns nine casings at the same time, running entirely in the browser, so nothing internal leaves the machine.

What naming convention does your team enforce — and do you enforce it with a test, or with a convention doc nobody rereads?

Why Your Diff Shows Every Line Changed (And It's Not Your Code)

zhihu wu — Sat, 26 Sep 2026 13:02:11 +0000

You open a pull request. You changed one line. The diff is 412 lines.

You blame the linter, then yourself. Usually it's neither. A diff compares characters before it compares meaning, and the characters that changed are invisible.

1. Line endings: CRLF vs LF

The classic culprit. A file written on Linux ends its lines with \n; a file written on Windows ends them with \r\n. Git stores bytes, so the moment a teammate's editor (or a script, or a Windows tool) rewrites the file with the other convention, every single line differs by one byte you cannot see.

To confirm it, run git diff --ignore-cr-at-eol. If the 412-line diff collapses to your one real change, that's your answer. When the two versions are not in git yet — two config files, two API response dumps — I paste both into the Diff Checker and flip the "ignore whitespace" toggle. It runs entirely in the browser, so pasting a private config is not a concern.

2. Trailing whitespace

Editors with "trim trailing whitespace on save" enabled rewrite every line they touch, and any formatter run rewrites the whole file. You get lines marked as changed that look byte-identical, because the difference sits at the end, past where your eye stops rendering.

3. Tabs vs spaces, and indent conversion

One contributor's editor converts indentation on save. Every nested block now reads as "modified". git diff -w (ignore all whitespace) collapses it instantly — and if it does, you know the change is cosmetic.

4. Encoding and BOM

A BOM added by a Windows editor, or a latin-1 → UTF-8 rewrite, changes every line containing a non-ASCII character. file on both versions tells you the encoding, and a suspiciously huge git diff --stat on a mostly-ASCII file is the hint.

The habit that fixes it permanently

.gitattributes with * text=auto eol=lf normalizes line endings at commit time, once, for everyone.
.editorconfig with end_of_line = lf, insert_final_newline = true, trim_trailing_whitespace = true so every editor agrees on the rules.
Review with git diff -w before you push. If the diff disappears, the change is whitespace-only: revert it or commit it on its own, so the real change stays reviewable.

A diff never lies — it compares characters. When its report looks impossible, check the invisible ones first: end-of-line bytes, trailing spaces, indentation, encoding. A whitespace-aware diff view is the fastest way to stop guessing and get back to your actual change.

A Day Is Not 86400 Seconds: The DST Bug in Your Date Math

zhihu wu — Thu, 24 Sep 2026 13:02:29 +0000

Most "date bugs" I've had to chase in production weren't off by a timezone. They were off by exactly one day, and they only appeared twice a year.

The bug

// "tomorrow, same time"
const tomorrow = new Date(Date.now() + 86400 * 1000);

That code is correct 363 days a year. On the other two it is off by an hour, and if you round the result down to a date it is off by a whole day.

The epoch is absolute; calendar units are not

A Unix timestamp is a fixed instant. 1758700800 is the same moment in Lagos, Lisbon and Lima - only the rendered local time differs. Arithmetic in seconds is therefore always exact in absolute time, and that is the trap: "one day later" is not an absolute duration. It is a calendar operation whose length depends on the timezone rules in effect at both moments.

A spring-forward day is 82,800 seconds long; a fall-back day is 90,000. Add exactly 86,400 seconds to local midnight and you land at 01:00 (already past the boundary you wanted) or at 23:00 of the day before.

Same bug, four languages

// adds exactly 86400 s - wrong across a DST boundary
Instant.now().plus(Duration.ofDays(1));
// calendar-aware - what you usually mean
ZonedDateTime.now(zone).plusDays(1);

new Date(Date.now() + 86400 * 1000);              // +86400 s exactly
const d = new Date(); d.setDate(d.getDate() + 1); // one calendar day

Go's t.Add(24 * time.Hour) is a duration; t.AddDate(0, 0, 1) is a calendar day. In SQL, date_add(d, interval 1 day) follows the zone while d + interval 86400 second does not. Python is the sneakiest: dt + timedelta(days=1) is wall-clock arithmetic on naive datetimes, but adding timedelta to an aware datetime in DST-aware zones can still surprise you.

What actually fixes it

Store the absolute instant - epoch seconds or UTC ISO 8601. Timestamps do not have DST.
Make "which calendar day is this?" decisions in the user's timezone (the zone, not an offset: an offset is a snapshot, a zone is a rule set with a history).
For "yesterday's rows", compute the day boundaries as calendar days in that zone and convert those boundaries to instants - instead of subtracting 86400 from now.
Put a DST date in your test suite. Twice a year is exactly often enough to forget.

When one of these bites, the first move is converting the raw epoch values in the logs to local time. I use the timestamp converter on CodeToolbox for that - it shows local and UTC side by side and auto-detects seconds vs milliseconds, which is the other half of this bug family, and it runs entirely in the browser so staging log values never leave the machine.