JavaScript’s internationalization and location APIs can produce results that look reasonable but mean something different from what your application intended. Set locale, time zone, currency, coordinate order, datum, and units explicitly at system boundaries—and keep machine values separate from display text.
1. Date formatting can inherit the runtime’s defaults
Intl.DateTimeFormat uses the runtime’s default locale and time zone when you do not specify them. That means the same code can display differently on different devices or execution environments. When output must follow a particular audience or region, pass both values explicitly:
As an Amazon Associate I earn from qualifying purchases.
const formatter = new Intl.DateTimeFormat("en-GB", {
timeZone: "America/New_York",
dateStyle: "medium",
timeStyle: "short"
});
formatter.format(new Date("2026-10-11T15:00:00Z"));The locale controls conventions such as date ordering and wording; the IANA time-zone identifier controls which local time is shown. Identifiers include America/New_York and Australia/Sydney. See MDN’s Intl.DateTimeFormat reference for options and examples.
Free tools Windows power users keep installed
One-click scans. No signup required.
To check what the runtime actually selected—including defaults—inspect resolvedOptions():
#1 Best Overall
console.log(formatter.resolvedOptions());This returns the effective locale, calendar, numbering system, and time zone, among other formatter settings. It is useful for diagnosing a mismatch between an intended configuration and the formatter’s resolved behavior.
2. An instant is not the same thing as a local appointment time
A JavaScript Date represents an instant. Formatting that date in another time zone changes how the instant is displayed; it does not move the instant forward or backward. For example, one event can be shown as different wall-clock times in New York and Sydney while remaining the same point in time.
Rank #2
Recurring events such as “the meeting is at 9 a.m. every Monday in New York” have a different meaning from a fixed timestamp. For that kind of schedule, store the local date and time together with its governing time zone rather than relying on an unqualified timestamp. This is application data-model guidance: Intl.DateTimeFormat formats instants but does not define a complete recurring-event model.
3. Locale and currency are separate inputs
For currency output, provide both a locale and a currency code. The locale determines display conventions; the code identifies the currency. A locale alone is not a dependable way to choose whether an amount means dollars, euros, or yen.
const amount = 1234.5;
new Intl.NumberFormat("en-US", {
style: "currency",
currency: "USD"
}).format(amount);
new Intl.NumberFormat("de-DE", {
style: "currency",
currency: "EUR"
}).format(amount);The currency option takes a code such as USD, EUR, or JPY. Display conventions can also affect fractional digits: JPY formatting, for example, illustrates that minor-unit display conventions are not the same as USD’s. Consult MDN’s Intl.NumberFormat options reference and its internationalization guide.
4. Localized strings are for people, not data exchange
Do not parse or compare formatted date and currency strings as if they were stable machine values. MDN notes that output may vary between implementations, even for the same locale, and may contain non-breaking spaces or bidirectional control characters. A string that appears visually identical can therefore differ at the code-point level.
Rank #4
Keep the underlying timestamp or numeric amount as data, and format it only when presenting it to a user. Avoid hardcoding localized output in tests as though every runtime must emit precisely the same sequence of characters. If you need a stable interchange format, define one separately from the localized display.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 115. Browser geolocation and GeoJSON use different coordinate order
Browser geolocation exposes coordinates as named properties: latitude and longitude. GeoJSON geographic positions use an array with longitude first and latitude second: [longitude, latitude]. Copying values into an array without checking the contract can silently swap the location.
const position = await new Promise((resolve, reject) => {
navigator.geolocation.getCurrentPosition(resolve, reject);
});
const { latitude, longitude } = position.coords;
const geoJsonPosition = [longitude, latitude];RFC 7946 specifies the order: “The first two elements are longitude and latitude, or easting and northing, precisely in that order and using decimal numbers.” See RFC 7946, section 3.1.1, and MDN’s reference for browser GeolocationCoordinates.
6. Coordinates also need a datum, units, and boundary rules
Two numbers do not fully describe a geographic position. GeoJSON geographic coordinates use decimal degrees in the WGS 84 coordinate reference system. An optional third position value represents elevation in meters relative to the WGS 84 reference ellipsoid. RFC 7946 advises implementations not to extend positions beyond three elements because the meaning of extra values is ambiguous. See RFC 7946, *The GeoJSON Format*.
Preserve accuracy and observation time
Browser geolocation data includes accuracy and a measurement timestamp alongside latitude and longitude. If an application uses a position to make decisions, retain or account for those fields where relevant; coordinates alone do not communicate how certain or how recent the observation is. MDN documents the coordinate properties in its GeolocationCoordinates reference.
Do not assume every bounding box is an ordinary min-to-max range
A GeoJSON bounding box that crosses the antimeridian can have an east longitude smaller than its west longitude. Code that always treats the west value as the minimum and east as the maximum can misinterpret the region. RFC 7946 includes antimeridian examples; use its specified bounding-box conventions rather than applying ordinary numeric range assumptions to every case.
Quick Recap
Boundary checklist
- Pass the intended locale and time zone when date output must be predictable.
- Keep the event’s meaning clear: a fixed instant or a local recurring schedule tied to a time zone.
- Specify a currency code independently from the locale.
- Keep timestamps and numeric amounts separate from localized display strings.
- Convert coordinates by property name, and document whether arrays use longitude-first ordering.
- Record coordinate datum and units, and account for accuracy, observation time, and antimeridian cases when they matter.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
