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).
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.
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.
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
maxTimeDifferenceafter you decrease maxTimeDifference.