How we handle timezones for our international customers
Software translated into French, English, and Spanish gives the impression of being ready for international use. In reality, interface language and data timezone are completely independent — and it's the second one that silently breaks "today" or "this week" reports if it's not handled properly.
The trap: translating isn't localizing
Anything with a notion of "day" — a "today" report, a "this week" range, a scheduled reminder — depends on a timezone. If that timezone is hardcoded to the server's, a company located elsewhere in the world will see skewed numbers: a stock movement logged at 10pm local time might already be "tomorrow" on the server, and missing from the "today" report they're looking at.
Why "the country" isn't enough either
Even fixing it per country doesn't solve everything: a single country can span several timezones (mainland France and its overseas territories, for instance, with gaps of several hours). The only reliable level is an explicit timezone, chosen individually, independent of language and declared country.
What we built at Fluxalyo
Every company declares its own timezone (a standard identifier, like "Europe/Paris" or "Asia/Tokyo", not a fixed offset that would break at the daylight-saving transition) — auto-detected at signup, but always editable. "Today" and period-based reports rely on that timezone, not on our server's.
Frequently asked questions
?Do I need to change anything if I'm in France?+
No, the timezone is auto-detected at signup and already matches your location — nothing to do unless you change location.
?What if my company has sites in several different timezones?+
Today, a single timezone applies to the whole company. If your sites are in very different timezones, reach out and we can talk it through.
Ready to take back control of your stock?
Create my account