HP Integrity NonStop J-Series - Manual (Page 242)

Europe, and "no DST". But what about places that follow other rules, such as Argentina, where
spring begins in September and summer ends in March?
RWZoneSimple is table-driven; if the rule is
simple enough, you can construct your own table of type RWDaylightRule, and specify it as you
construct an RWZoneSimple. For example, imagine that DST begins at 2 a.m. on the last Sunday in
September, and ends the first Sunday in March. Simply create a static instance of RWDaylightRule:
static RWDaylightRule sudAmerica =
{ 0, 0, TRUE, {8, 4, 0, 120}, {2, 0, 0, 120}};
(See the documentation for RWZoneSimple for details on what the numbers mean.) Then construct an
RWZone object:
RWZoneSimple ciudadSud( RWZone::Atlantic, &sudAmerica );
Now you can use ciudadSud just like you used paris or newYork above.
But what about places where the DST rules are too complicated to describe with a simple table, such
as Great Britain? There, DST begins on the morning after the third Saturday in April, unless that is
Easter, in which case it begins the week prior! For such jurisdictions, you might best use standard
time, properly labeled. If that just won't do, you can derive from
RWZone and implement its interface
for Britain alone. This strategy is much easier than trying to generalize a case to handle all
possibilities including Britain, and it's smaller and faster besides.
The last time problem we will discuss here is that there is no standard way to discover what DST
rules are in force for any particular place. In this the Standard C Library is no help; you must get the
information you need from the local environment your application is running on, perhaps by asking
the user.
One example of this problem is that the local wall clock time RWZone instance is constructed to use
North American DST rules, if DST is observed at all. If the user is not in North America, the default
local time zone probably performs DST conversions wrong, and you must replace it. If you are a user
in Paris, for example, you could solve this problem as follows:
RWZone::local(new RWZoneSimple(RWZone::Europe, RWZone::WeEu));
If you look closely into <rw/locale.h>, you will find that RWDate and RWTime are never mentioned.
Instead, RWLocale uses the Standard C Library type struct tm. RWDate and RWTime both provide
conversions to this type, and you may prefer using it directly rather than using RWTime::asString().
For example, suppose you must write out a time string containing only hours and minutes; e.g.,12:33.
The standard formats defined for strftime()and implemented by RWLocale don't include that option,
but you can fake it. Here's one way:
RWTime now = RWTime::now();
cout << now.hour() << ":" << now.minute() << endl;
Without using various manipulators, this code might produce a string like 9:5. Here's another option:
RWTime now = RWTime::now();
cout << now.asString('H') << ":" << now.asString('M') << endl;
This produces 09:05.
In each of the previous examples, now is disassembled into component parts twice, once to extract