-
-
-
- @b Subtraction
-
-
-
-
- the same types of operations as above are
- allowed and, additionally, a difference between two wxDateTime objects can be
- taken and this will yield wxTimeSpan.
-
-
-
-
-
- @b Multiplication
-
-
-
-
- a wxTimeSpan or wxDateSpan object can be
- multiplied by an integer number resulting in an object of the same type.
-
-
-
-
-
- @b Unary minus
-
-
-
-
- a wxTimeSpan or wxDateSpan object may finally be
- negated giving an interval of the same magnitude but of opposite time
- direction.
-
-
-
-
-
- For all these operations there are corresponding global (overloaded) operators
- and also member functions which are synonyms for them: Add(), Subtract() and
- Multiply(). Unary minus as well as composite assignment operations (like +=)
- are only implemented as members and Neg() is the synonym for unary minus.
-
- @section tdatetimezones Time zone considerations
-
- Although the time is always stored internally in GMT, you will usually work in
- the local time zone. Because of this, all wxDateTime constructors and setters
- which take the broken down date assume that these values are for the local
- time zone. Thus, @c wxDateTime(1, wxDateTime::Jan, 1970) will not
- correspond to the wxDateTime Epoch unless you happen to live in the UK.
- All methods returning the date components (year, month, day, hour, minute,
- second...) will also return the correct values for the local time zone by
- default, so, generally, doing the natural things will lead to natural and
- correct results.
- If you only want to do this, you may safely skip the rest of this section.
- However, if you want to work with different time zones, you should read it to
- the end.
- In this (rare) case, you are still limited to the local time zone when
- constructing wxDateTime objects, i.e. there is no way to construct a
- wxDateTime corresponding to the given date in, say, Pacific Standard Time.
- To do it, you will need to call #ToTimezone or
- #MakeTimezone methods to adjust the date for
- the target time zone. There are also special versions of these functions
- #ToUTC and #MakeUTC for
- the most common case - when the date should be constructed in UTC.
- You also can just retrieve the value for some time zone without converting the
- object to it first. For this you may pass TimeZone argument to any of the
- methods which are affected by the time zone (all methods getting date
- components and the date formatting ones, for example). In particular, the
- Format() family of methods accepts a TimeZone parameter and this allows to
- simply print time in any time zone.
- To see how to do it, the last issue to address is how to construct a TimeZone
- object which must be passed to all these methods. First of all, you may construct
- it manually by specifying the time zone offset in seconds from GMT, but
- usually you will just use one of the @ref datetime_overview and
- let the conversion constructor do the job.
- I.e. you would just write
-
- @code
- wxDateTime dt(...whatever...);
- printf("The time is %s in local time zone", dt.FormatTime().c_str());
- printf("The time is %s in GMT", dt.FormatTime(wxDateTime::GMT).c_str());
- @endcode
-
-
- @section tdatedst Daylight saving time (DST)
-
- DST (a.k.a. 'summer time') handling is always a delicate task which is better
- left to the operating system which is supposed to be configured by the
- administrator to behave correctly. Unfortunately, when doing calculations with
- date outside of the range supported by the standard library, we are forced to
- deal with these issues ourselves.
- Several functions are provided to calculate the beginning and end of DST in
- the given year and to determine whether it is in effect at the given moment or
- not, but they should not be considered as absolutely correct because, first of
- all, they only work more or less correctly for only a handful of countries
- (any information about other ones appreciated!) and even for them the rules
- may perfectly well change in the future.
- The time zone handling #methods use these functions
- too, so they are subject to the same limitations.
-
- @section tdateholidays wxDateTime and Holidays
-
- TODO.
-
- @section tdatecompatibility Compatibility
-
- The old classes for date/time manipulations ported from wxWidgets version 1.xx
- are still included but are reimplemented in terms of wxDateTime. However, using
- them is strongly discouraged because they have a few quirks/bugs and were not
- 'Y2K' compatible.
-
- */
-
projects / wxWidgets.git / blobdiff