Most web apps display timestamps - when a record/item/comment… was created, modified or deleted. Good automation or QA should deal with timestamps between its scripts and the app even if

Commands allows you to do most of this robustly and easily. (Support for timezones depends on Mozilla implementing some of ThirdPartyIssues).

Why timestamps are not trivial

Getting script timestamps

The script drives the application, which records a timestamp (in app DB). That timestamp will show up on the next or later page (or on the same page in an element updated via ajax). The script could parse that timestamp and store it in its DB - but that could prevent it from detecting app errors. The script, therefore, always generates its own timestamps. Then it uses them to validate timestamps parsed from the application.

Issues with timestamps

The above situations cause

Commands solves it by introducing delays, where needed for robust comparison of parsed app timestamps and generated and stored script timestamps. The Selenese commands are sleepUntilTimestampDistinctDownToMilliseconds, sleepUntilTimestampDistinctDownToSeconds and sleepUntilTimestampDistinctDownToMinutes.

If you are testing performance/responsiveness of the web application, you could balance the negative effect of delays by throttling down application resources.


This is pending Firefox Internationalisation API.

Configuration of time sync difference

Commands adds field maxTimeDifference to Settings module extensions.selite-settings.common. It’s the max. time difference between the server and your script machine (in milliseconds).

Beware: If you run script(s) that record timestamps, and then you decrease maxTimeDifference later below a threshold needed by the already recorded timestamps, the recorded timestamps may cause false positive errors later. To prevent that either

after you decrease maxTimeDifference.