Thursday, July 21, 2005

Importance of UTC date normalization in event triggers.

One important aspect of internationalizing an application may be that of date handling. That is, how will the application read and write dates. Should the scope of the project be limited to viewing only, then the point is moot. However, if the need arises that these dates drive some activity or event then "normalizing" the dates should be heavily considered. Choosing an international standard (UTC) and conforming date entries allows date-specific operations and triggers to be precisely executed.

Consider the following example. An organization has dates that drive specific events or triggers. A monitor/daemon is run that periodically evaluates these dates and fires the appropriate action. Presume the monitor awakes at midnight MST. Then the scenario in which an organization in New Zealand depends on the date of 24 July to trigger some action will then be delayed for 33 hours--and the people/systems dependent upon those date-driven operations will be hosed. Here's how:

    00:00 Denver July 23 the monitor awakes. Monitor evaluates all dates
    for 23 July and invokes appropriate operations.
    However, the New Zealand organization will not be processed yet,
    awaiting for midnight Denver on July 24.
    BUT, 00:00 Denver July 23 is 19:00 NZ July 24. The time difference
    is 19 hours. So, the New Zealand organization must wait until 00:00
    Denver July 24. So, 19h + 24h = 43h before the effective date
    processing occurs.

Alternatively, if the effective date is stored as a timestamp (even though only the "date" is really relevant considering the requirement to run operations based on "that day") and the monitor runs hourly the problem is solved. The New Zealand "date" of 00:00 July 24 is really 12:00 July 23 UTC. If the monitor then only evaluates per-hour dates, the application can then address international needs required by the effective date handling. Thus, all triggers and date dependent operations will only ever be delayed by an hour and ensuring that at midnight for any given timezone the correct operations for that timezone's day will be executed.

No comments: