DineGlobeDocs

Docs / Platform & trust / Languages, time zones & money

Languages, time zones & money

The three interface languages, venue-local time display, daylight-saving edge cases and exact-integer money formatting.

GuestHostManagerOwner

DineGlobe is built for venues that serve guests in more than one language and time zone, so three things are never ambiguous on any screen: which language you are reading, whose clock a time belongs to, and exactly how much money an amount is. This page explains the three interface languages, how times are shown and why the venue’s time zone is always named, how daylight-saving edges are handled on the booking grid, and how money is stored and rendered down to the exact minor unit.

Three interface languages

The reviewed interface catalogue has three locales:

Locale Written as Direction Clock
English en left to right 12-hour
Japanese ja left to right 24-hour
Arabic ar right to left (RTL) 12-hour

The landing page says it directly: “Reviewed in English, Japanese and Arabic — including right-to-left layout.” Arabic renders right to left wherever it is active, and the layout direction follows it.

When a screen is asked for a locale that has no reviewed pack — a regional variant such as a ja-JP style tag resolves to its base language first — the interface falls back to English and says so with a notice that names the missing locale. Nothing is ever shown half-rendered in a mix of packs.

Transactional email covers two locales, English and Japanese, with the same fallback rule: any other locale receives English, and the rendered locale is reported rather than assumed. Required booking-policy text must cover the venue’s default language plus its supported languages before a venue can publish, so a guest never has to accept terms they cannot read.

Times are always the venue’s clock

Every time a guest or staff member sees is rendered in the venue’s own IANA time zone, and the zone is named beside the time. A booking line reads like “{date}, {time} ({time zone})” — for example a venue in America/New_York always shows Eastern time with the zone name attached, whether the reader’s device sits in Tokyo or Lisbon.

Three facts hold everywhere:

  • The stored instant is UTC and is never silently converted. Screens that show the raw record say it outright: “Stored exactly as {utc} (UTC); never converted to your device time.”
  • The locale decides the clock style. The same instant renders as a 12-hour time in English or Arabic and a 24-hour time in Japanese. A deterministic 24-hour stamp in Latin digits always accompanies the locale-aware format, so there is always one unambiguous rendering.
  • Emails stamp the same shape. Confirmation and reminder emails carry lines like “{YYYY-MM-DD HH:mm} ({time zone})” — the venue’s zone, not the recipient’s.

Business date, wall time and UTC instants

DineGlobe keeps three ideas separate, and no screen blends them:

Concept What it is How it appears
Business date The venue’s local service day YYYY-MM-DD, computed in the venue’s zone — a 23:30 booking and its 01:00 cleanup share the date the venue calls it
Wall time The venue-local clock reading HH:mm, shown beside the named zone
UTC instant The exact stored moment The value the system books, checks and deduplicates against

The booking date picker’s earliest selectable day is “today in the venue’s zone” — not in yours — and every slot you see is pinned to an explicit UTC instant before it can be booked.

Daylight-saving: repeat and gap notices

On a daylight-saving transition day, an ordinary clock would make one wall time mean two moments (fall back) or erase a wall time entirely (spring forward). DineGlobe does neither silently:

  • On a fall-back day, a repeated wall time is disclosed and offered twice: “The clock repeats: {time} happens twice on this date in {time zone}. Choose the first or second occurrence.” The two occurrences are two distinct bookable slots.
  • On a spring-forward day, a vanishing wall time is refused, never guessed: “{time} does not exist on this date in {time zone} (the clock jumps forward). Pick another time.”

The same discipline reaches the waitlist: a queue token that would expire at a midnight inside a spring-forward gap expires at 01:00 instead, and an ambiguous midnight expires at its last real occurrence — the estimate is honest even at the edge.

Money: exact integer minor units

All money is stored and computed as exact integer minor units — no floating-point anywhere, and no automatic currency conversion exists in the system. An amount booked in one currency stays in that currency for its whole life. Guest-facing terms put it plainly: “Charged in {currency}; the exact amount {amount} never changes with your region.”

Currencies carry different numbers of decimals, and rendering follows the currency’s own minor-unit set:

Decimals Currencies 4950 minor units equal
0 JPY, KRW, VND, CLP, ISK, TWD, DJF, GNF, PYG, RWF, UGX, VUV, XAF, XOF, XPF 4950 whole units
2 everything else (incl. USD, EUR, INR, GBP) 49.50
3 KWD, BHD, OMR, JOD, IQD, LYD, TND 4.950

Two honesty details worth knowing:

  • Where terms are shown before you commit, amounts can appear in raw minor units on purpose — the pilot booking flow shows a deposit line as “Deposit required at booking: {amount} minor units ({currency})” rather than dressing the number up.
  • Reports and finance views keep currencies separate: totals aggregate per currency and are never combined across currencies. A rate whose denominator is zero reads “not applicable” rather than 0%.