Some times the smallest parameter can have a great effect, check this video where I discover the might of the number nine 🙂
In this video, Erik demonstrates a powerful yet often overlooked feature in AL and Business Central: the magic number 9 used as a format number parameter. This simple trick ensures that dates, times, and numbers are formatted (and parsed) in a language- and region-independent way using the international ISO/XML standard format — eliminating a whole class of localization bugs.
The Problem: Region-Dependent Formatting
Business Central automatically formats dates, numbers, and times according to the user’s region and language settings. While this is great for display purposes, it can cause serious issues when you’re exchanging data between systems, building export/import files, or deploying code across multiple countries.
For example, if your settings are configured for Denmark, today’s date might display as DD-MM-YYYY. Switch to English (Canada), and you’ll see YYYY-MM-DD. Move to Croatia, and the format changes again — this time with dots as separators.
This variability is fine for end-user display, but it becomes dangerous when your software depends on a consistent format — for instance, when generating bank files or exchanging data between components deployed in different countries.
The Magic Number 9: Format and Evaluate
How Format Works Implicitly
When you substitute a non-string value into a string in AL (e.g., using Message), there’s an implicit Format command being executed. These two lines are functionally identical:
Message('%1', Today);
Message('%1', Format(Today));
If you’re passing a string, it simply gets substituted. If you’re passing a non-string (like a Date, DateTime, or Decimal), Format is called behind the scenes to convert it to a string.
Using 9 with Format
The Format function accepts additional parameters. The first optional parameter is the length (use 0 to let it auto-size), and the second is the format number. This is where the magic number 9 comes in:
Format(Today, 0, 9)
By specifying 9 as the format number, you get the XML/ISO standard format — regardless of the user’s region settings. For dates, this means YYYY-MM-DD. For datetimes, you get the full ISO 8601 representation. No matter if you’re in Canada, Croatia, or Denmark, the output is always the same.
Dates and DateTimes
Erik demonstrates this by comparing a regular datetime with a formatted one:
Message('%1 %2', CurrentDateTime, Format(CurrentDateTime, 0, 9));
In Croatia, the regular format shows a date with dots and a time without seconds. The format-9 version shows the standard ISO datetime format — consistent every time.
Numbers and Decimals
The same principle applies to numbers. In Croatia, the dot is the thousand separator and the comma is the decimal separator. In the international (format 9) representation, there is no thousand separator and the dot is the decimal separator:
Message('%1 %2', 123456.789, Format(123456.789, 0, 9));
Using 9 with Evaluate
The magic number 9 doesn’t just work for creating formatted strings — it also works when parsing them with Evaluate. This is critical for data import scenarios.
Consider the source code from the demo:
pageextension 50100 CustomerListExt extends "Customer List"
{
trigger OnOpenPage();
var
d, d2 : Decimal;
begin
if Evaluate(d, '123456,789', 9) then;
if Evaluate(d2, '123678.789', 9) then;
message('%1 %2', d, d2);
end;
}
When you pass 9 as the third parameter to Evaluate, it tells Business Central to interpret the string using the international ISO format. This means it expects a dot as the decimal separator and no thousand separators. So '123678.789' evaluates correctly, while '123456,789' — which uses a comma — will fail to parse as expected under format 9.
Without the format number 9, the parsing behavior depends on the user’s region. Erik highlights how dangerous this can be: in Croatia, a comma is the decimal separator, so '123,456' would be interpreted as roughly 123.456 (one hundred twenty-three point four five six). But in a region where the comma is a thousand separator, the same string would be interpreted as 123456 — off by a factor of a thousand. Even worse, dates with ambiguous numbers (like 23/7/5) could be silently reinterpreted as entirely different dates.
A Practical Use Case
Erik shares a common real-world scenario: you build a data export job and a matching data import job. Everything works perfectly on your machine because both components run in the same region with the same localization settings. But then one component gets deployed to Sweden and the other to Croatia — and suddenly numbers are off by a factor of a thousand, or dates are flipped around silently.
By consistently using format number 9 in both your Format and Evaluate calls, you ensure that the data is always written and read in the same international format, regardless of where each component is running.
Summary
The magic number 9 in AL tells both Format and Evaluate to use the international ISO/XML standard format for dates, times, and numbers. This simple parameter eliminates region-dependent formatting issues and is essential whenever you’re:
- Building data export/import files (bank files, EDI, etc.)
- Exchanging data between systems or components that may run in different regions
- Storing formatted values that need to be reliably parsed later
- Writing code that must work consistently across all localizations
It’s a small detail that can save you from subtle, hard-to-diagnose bugs — especially the kind that “almost work” and silently corrupt your data.
