Skip to main content

Every date follows the shop's clock

StorM2 min readBYTHECLOUD ENT

How the shop layer of StorM Web Engine reads dates and times, and how each release is checked against the business clock instead of the server's or the visitor's.

One clock per shop

Every shop states its own time zone in its settings, and the engine reads its dates and times in that zone: pickup and delivery days, cut-off times, opening hours, sale and discount dates, the times printed in mail and receipts, daily totals and scheduled jobs. There is no default: without a zone the module check fails, the date calculations refuse to run and date displays stay blank, because a guessed zone is a wrong zone for someone.

Three tempting clocks are avoided. The server's own zone is usually UTC in production. The visitor's device zone changes with every traveller. A fixed offset such as minus seven hours is wrong for half the year wherever clocks change, and wrong for good once a region changes its rule.

Where the clock rules come from

Daylight-saving and rule changes come from a time-zone table the engine carries, compiled from an official release of the time-zone database, and not from the host machine or the visitor's browser, whose copies can be older than a region's current rule. The runtime's own data is only a cross-check: when it disagrees, the mismatch is reported once for that zone. The one place that still reads its device's own data is a store TV screen, and only when its page carries no shop clock that covers the moment.

How a release is checked

A date computed from the wrong clock cannot be seen on the machines where shops are built, because their clock zone is often the shop's own. It goes wrong in production, every evening, and for every visitor abroad. So before a release, the check runs the shop the way production runs it:

  • The server runs in UTC with a movable clock, using the same build.
  • Visitors open the shop from several device time zones at once, with each browser's clock set to the same instant.
  • The check visits the moments the shop's gate file lists, such as either side of UTC midnight, local midnight, month end, week end, the days clocks change, and five minutes either side of a cut-off.
  • At each moment it compares what the shop offers, accepts and stores with what the business clock says; mailed dates are checked on the test orders the shop's gate file lists.

Any difference fails the release.

Published with BWS

More from Research

  1. StorMCard terminals: the rules for pairing and revokingThe rules the shop engine follows when a card terminal is registered, paired and revoked, and for sales that were still waiting on a terminal when it was revoked.
  2. StorMUnknown is not zeroThe shop engine does not guess: in four places an unreadable amount stays unknown, a total with an unknown part is marked incomplete, an unknown gift stock gives no gift, and an unexpected delivery is listed as such.
  3. StorMStorM Web Engine: what loads up frontCompressed size of the code StorM Web Engine loads up front, as a site ships it, and the budget it is held to.