Tools.h++ Manual

4-6 104011 Tandem Computers Incorporated
4
<iostream.h> . For money, the main problem is that there is no standard
internal representation for monetary values. Fortunately, none of these
problems is overwhelming.
Time
Let us consider the time zone problem. Our first observation is that there is no
simple relationship between time zones and locales. All of Switzerland shares
a single time zone, including DST rules, but has four official languages (French,
German, Italian, and Romansch). Hawaii and New York, on the other hand,
share a common language but occupy time zones five hours apart; or
sometimes six hours apart, because Hawaii does not observe DST.
Furthermore, time zone formulas have little to do with cultural formatting
preferences. Thus, we use a separate time zone object, rather than letting
RWLocale subsume time zone responsibilities.
In Tools.h++, the class RWZone encapsulates knowledge about time zones. It is
an abstract class; we have implemented its interface in the class
RWZoneSimple . Three instances of RWZoneSimple are constructed at startup,
to represent local wall clock time, local Standard time, and Universal time
(GMT). Local wall clock time includes any Daylight Savings Time in use.
Whenever you convert an absolute time (as in the class RWTime ) to or from a
string, an instance of RWZone is involved. By default, the local time is
assumed, but you can pass a reference to any RWZone instance.
It’s time for some examples. Imagine you have scheduled a trip from New
York to Paris. You will leave New York on December 20, 1993, at 11:00 PM, and
return on March 30, 1994, leaving Paris at 5:00 AM, Paris time. What will the
clocks show at your destination when you arrive?
First, let’s construct the time zones and the departure times:
RWZoneSimple newYorkZone(RWZone::USEastern, RWZone::NoAm);
RWZoneSimple parisZone (RWZone::Europe, RWZone::WeEu);
RWTime leaveNewYork(RWDate(20, 12, 1993), 23,00,00, newYorkZone);
RWTime leaveParis (RWDate(30, 3, 1994), 05,00,00, parisZone);