One common problem when handling dates and times, is that time is shown and
entered as local, whereas the computer should better use
non-geographic information - especially on a Client-Server architecture, where
both ends may not be on the same physical region.
A time zone is a region that observes a uniform standard time for
legal, commercial, and social purposes.
Time zones tend to follow the boundaries of countries and their subdivisions
because it is convenient for areas in close commercial or other communication
to keep the same time.
Most of the time zones on land are offset from Coordinated Universal
Time (UTC) by a whole number of hours, or minutes.
Even worse, some countries use daylight saving time for part of the year,
typically by changing clocks by an hour, twice every year.
The main rule is that any date and time stored should be stored in
UTC, or with an explicit Zone identifier (i.e. an explicit offset to
the UTC value).
Our framework expects this behavior: every date/time value stored and handled
by the ORM, SOA, or any other part of it, is expected to be UTC-encoded.
At presentation layer (e.g. the User Interface), conversion to/from local times
should take place, so that the end-user is provided with friendly clock-wall
As you may guess, handling time zones is a complex task, which should be
managed by the Operating System itself.
Since this cultural material is constantly involving, it is updated as part of
In practice, current local time could be converted from UTC from the current
system-wide time zone. One of the only parameters you have to set when
installing an Operating System is to pickup the keyboard layout... and the
current time zone to be used. But in a client-server environment, you may have
to manage several time zones on the server side: so you can't rely on this
One sad - but predictable - news is that there is no common way of encoding
time zone information.
Under Windows, the registry contains a list of time zones, and the
associated time bias data. Most POSIX systems (including Linux and Mac
OSX) do rely on the IANA database, also called
tzdata - you may
have noticed that this particular package is often updated with your
Both zone identifiers do not map, so our framework needed something to be
shared on all systems.