This section describes the behavior of dates and date/times in Cúram.
Take a look at these examples:
- The server is in time zone "GMT". A user is in time zone "GMT -01". At 15:00 GMT the user registers a new person, and the server-side processing timestamps a resulting database record with the time 15:00. Twenty seconds later the user performs a query and sees the timestamp displayed in the client user interface as 14:00. The user's clock is showing 14:00:20 - the new record's timestamp is twenty seconds in the past - just what the user expected.
- The user registers a new case at 23:30 local time on 01-Jul-2003. The server's local time is 00:30 on 02-Jul-2003, so it creates the case with a case start date of 02-Jul-2003. The user immediately performs a query on all cases registered on 01-Jul-2003. The newly registered case is not found.
In the second example, the server processing which records the current date as the case start date must convert from the current date (which is time zone dependent) to some fixed value that will henceforth be taken as the case start date. On the grounds of both simplicity and higher likelihood of meeting requirements, the server's local date is recorded.
The basis for how dates and date/times are handled is as follows:
- Dates are processed and displayed in a time zone-independent manner.
- Date/times are processed and displayed in the user's preferred time zone.
- The time zone of the server is used when converting from a date/time to a date (or vice versa).
The second issue was mentioned with an earlier example :- the fact that the user, on performing a search for today's cases, fails to find a record just registered. What caused this situation is as follows:
- The user carried out a transaction just before midnight, local time, on day 1. The server recorded a "start date" of day 2, based on converting it's current local date/time to a date.
- The user requested a list of transactions with a start date of day 1. Because this is a date, not a date/time the server treats it in a time zone independent manner. The newly registered record does not match the search criteria.
Searches on date/time ranges (such as the start/end of the user's local day) are only feasible if the column being searched on is itself date/time. Users will need to be aware that the current "business day" may not be the same date as the date in their local time zone. Fortunately, such situations are likely to be rare.