QA Testing for Date and Number Formatting

Dates and numbers seem like the safest things to display, which is exactly why their formatting bugs ship so often. A timestamp shown as month-day-year reads as a completely different date to most of the world. A score formatted with a period as a thousands separator looks like a tiny decimal to players who use the comma. These are not cosmetic nits; they make your game look broken and can mislead players about scores, dates, and quantities they care about. QA for formatting means deliberately running through locales whose conventions invert your defaults, and confirming every date and number reads correctly. This post shows how.

Never build date or number strings by hand

The root cause of almost every formatting bug is code that assembles a date or number as a string manually, hardcoding the separators and order that happen to match the developer's locale. The first thing to test for is the absence of this pattern: every user-facing date and number should pass through a locale-aware formatter that knows the conventions for the player's locale. Hand-built strings are correct in one place and wrong everywhere else.

Test that the formatter is actually fed the player's locale, not a fixed default. It is common to wire up proper formatting and then call it with a hardcoded locale, which produces correct-looking output that is still wrong for everyone outside that locale. Confirm the locale flows from the player's real setting through to the formatter at every display point, including dynamically generated UI and any text assembled from templates, which is where hand-built strings love to hide.

Test separators that invert across locales

The decimal and grouping separators flip between locales: where one uses a period for decimals and a comma for thousands, another does the exact opposite, and others use spaces or other marks for grouping. Test that a number like one thousand and a number like one point five render correctly in locales that swap these, because a swap turns a large grouped number into a tiny decimal or vice versa. This is the formatting bug most likely to actually mislead a player about a quantity.

Test large numbers and grouping specifically, since scores, currency, and resource counts are often big. Confirm grouping appears at the right intervals for the locale, that very large numbers do not lose digits or overflow their field, and that negative numbers and zero format correctly. A leaderboard score that reads as a thousand times larger or smaller than it is undermines the whole point of showing the number, so these separator tests guard against genuinely misleading output, not just ugliness.

Resolve ambiguous date orders

Date order is the great ambiguity: the same numeric date can mean two entirely different days depending on whether the locale expects day-month-year or month-day-year. Test that dates render in the player's expected order, and prefer formats that remove ambiguity where space allows, like a spelled-out or clearly ordered month. A date that a player misreads by months is worse than an obviously broken one, because they trust it and act on the wrong information.

Test the components around the date too: month and day names that must be translated and may be ordered differently, the first day of the week which is not universal, twelve versus twenty-four hour time, and time zone display. Confirm relative dates like yesterday or in three days are computed against the player's timezone and translated. Dates touch reset timers, event schedules, and save metadata, so a formatting error here ripples into the player misunderstanding when things happen.

Account for calendars and non-Latin numerals

Not every player uses the Gregorian calendar or Western Arabic numerals, and a fully localized game may need to respect that. Test that your formatting can present dates in alternative calendar systems where your locales require it, and that numerals render in the script the locale expects. This is deeper localization than many indie games attempt, but if you advertise support for a locale, getting its calendar and numerals right is part of the promise.

Even if you stay Gregorian, test that your date math is calendar-correct: leap years, month lengths, and the rollover at year boundaries. A naive calculation that assumes thirty-day months or ignores leap years will drift, and the error surfaces as a date that is simply wrong. Confirm that durations and date arithmetic use a proper date library rather than ad hoc math, because the calendar has more edge cases than it appears to, and players notice when a date lands on a day that does not exist.

Setting it up with Bugnet

Formatting bugs are reported as the date is wrong or the score looks weird, with no indication of the reporter's locale, which is the one piece of information you need. Bugnet's in-game report button captures device and platform context automatically, so a formatting complaint arrives with the device locale and platform attached, immediately pointing you at the locale whose conventions your code mishandles. Without that context, a swapped-separator bug is nearly impossible to reproduce from a generic complaint.

Formatting bugs cluster tightly by locale, so Bugnet's occurrence grouping folds duplicate reports into one issue with a count and shows you which locale is generating the most complaints. Add a custom field for the player's locale, then filter the dashboard to see whether the problem is a date-order issue in one region or a separator swap in another. Seeing the reports grouped by locale in one dashboard turns a vague stream of it looks wrong into a precise list of which locales your formatting forgot.

Build a locale pass into release

The only dependable way to catch formatting bugs is to actually view the game in locales that invert your defaults, so make a multi-locale display pass part of release. Pick a small set of locales that differ from your development one in date order, separators, and ideally calendar, and walk through every screen that shows a date or number. Pseudo-localization that stress-tests formatting can catch many issues automatically before a human ever looks.

Treat any hardcoded format or default locale found in review as a bug, even before it ships, because these are the seeds of the next formatting incident. The teams whose games feel native in every market are the ones who stopped trusting that numbers and dates are simple, routed everything through proper locale-aware formatting, and kept a handful of inverting locales in their test plan. It is a small discipline that prevents your game from looking broken to a large share of your players.

Dates and numbers are never as simple as they look. Route everything through locale-aware formatting and test the locales that invert your defaults.