Fieldpine use the date/time as reported by Windows, and we rely on this value being correct. Transactions are recorded using the date/time reported from Windows when needed.
It is not practical for Fieldpine to recreate their own date/time source rather than using Windows date/time. Reliable values such as date/time is something an operating system is meant to provide. The Point of Sale cannot reliably validate that the date/time is correct without communicating to another computer.
- If the date/time is incorrect now, change it using Windows.
- If possible you should enable NTP (Network Time protocol) which will verify the date/time periodically from Internet time servers.
- When the time is changed in Windows, the POS will record and potentially report this (if the POS is running).
- A System Primitive is recorded as Cause/Effect
- If the time difference is less than 15 minutes, take no futher action.
- Audit the TimeChange, typically raise an Event to Fieldpine.
- If enabled, warn the operator that the time was changed.
- During Startup, the POS checks that the date/time is wildly acceptable. Currently this is to verify that the year is between 2000 and 2045. If not the operator is advised and the POS will not start (unless /quick is present on the command line)
(22 Apr 2017, P1989). During startup and each time a sale is started the Point of Sale verifies that the current time reported from Windows is between:
"7 days ago" < "build time of the application" < "3700 days after application build time".
Essentially this check tests that your current date/time is after the time the program was compiled, but not more than around 10 years after the build date. If either of these checks fails, the user is warned, but not blocked (see note A)
(22 Apr 2017, P1989)If the date/time ever exceeds the optional setting "PlatformMaxDate", the user is warned not to continue, but not actually stopped (see note A). This setting is reserved for sites to set themselves to a future date. You must ensure you move this date forward on a regular basis.
- During startup, the Startup event sends the date/time to the event servers. These have alarms to detect large time differences from the server. This will not correct the problem, only increase the chance the problem will be noticed.
- If the clock is constantly reset to the same historic date on startup, check the CMOS battery on the motherboard. Most computers have a small button battery which powers the RTC.
- Some BIOS/hardware combinations can lose time when using hibernate or sleep modes. You will need to review the manufacturers site for details.
The default action is to continue with bad dates, based on the rule it is better to capture sales and fix later than block selling to a customer, however, some retailers may prefer to have the problem fixed first. If the setting PlatformCheckFailure=abort is defined, the POS will force exit after informing the user