]> git.saurik.com Git - wxWidgets.git/blame_incremental - docs/doxygen/overviews/datetime.h
Finished adding @tableofcontents to all overviews in the manual.
[wxWidgets.git] / docs / doxygen / overviews / datetime.h
... / ...
CommitLineData
1/////////////////////////////////////////////////////////////////////////////
2// Name: datetime.h
3// Purpose: topic overview
4// Author: wxWidgets team
5// RCS-ID: $Id$
6// Licence: wxWindows licence
7/////////////////////////////////////////////////////////////////////////////
8
9/**
10
11@page overview_datetime Date and Time
12
13@tableofcontents
14
15wxWidgets provides a set of powerful classes to work with dates and times. Some
16of the supported features of wxDateTime class are:
17
18@li Wide range: the range of supported dates goes from about 4714 B.C. to
19 some 480 million years in the future.
20@li Precision: not using floating point calculations anywhere ensures that
21 the date calculations don't suffer from rounding errors.
22@li Many features: not only all usual calculations with dates are supported,
23 but also more exotic week and year day calculations, work day testing,
24 standard astronomical functions, conversion to and from strings in either
25 strict or free format.
26@li Efficiency: objects of wxDateTime are small (8 bytes) and working with
27 them is fast
28
29There are 3 main classes declared in @c wx/datetime.h: except wxDateTime itself
30which represents an absolute moment in time, there are also two classes -
31wxTimeSpan and wxDateSpan - which represent the intervals of time.
32
33There are also helper classes which are used together with wxDateTime:
34wxDateTimeHolidayAuthority which is used to determine whether a given date is a
35holiday or not and wxDateTimeWorkDays which is a derivation of this class for
36which (only) Saturdays and Sundays are the holidays. See more about these
37classes in the discussion of the holidays (see
38@ref overview_datetime_holidays).
39
40Finally, in other parts of this manual you may find mentions of wxDate and
41wxTime classes. @ref overview_datetime_compat are obsolete and superseded by
42wxDateTime.
43
44
45
46@section overview_datetime_characteristics wxDateTime Characteristics
47
48wxDateTime stores the time as a signed number of
49milliseconds since the Epoch which is fixed, by convention, to Jan 1, 1970 -
50however this is not visible to the class users (in particular, dates prior to
51the Epoch are handled just as well (or as bad) as the dates after it). But it
52does mean that the best resolution which can be achieved with this class is 1
53millisecond.
54
55The size of wxDateTime object is 8 bytes because it is represented as a 64 bit
56integer. The resulting range of supported dates is thus approximatively 580
57million years, but due to the current limitations in the Gregorian calendar
58support, only dates from Nov 24, 4714BC are supported (this is subject to
59change if there is sufficient interest in doing it).
60
61Finally, the internal representation is time zone independent (always in GMT)
62and the time zones only come into play when a date is broken into
63year/month/day components. See more about timezones below
64(see @ref overview_datetime_timezones).
65
66Currently, the only supported calendar is Gregorian one (which is used even
67for the dates prior to the historic introduction of this calendar which was
68first done on Oct 15, 1582 but is, generally speaking, country, and even
69region, dependent). Future versions will probably have Julian calendar support
70as well and support for other calendars (Maya, Hebrew, Chinese...) is not
71ruled out.
72
73
74
75@section overview_datetime_timespandiff wxDateSpan and wxTimeSpan
76
77While there is only one logical way to represent an absolute moment in the
78time (and hence only one wxDateTime class), there are at least two methods to
79describe a time interval.
80
81First, there is the direct and self-explaining way implemented by
82wxTimeSpan: it is just a difference in milliseconds
83between two moments in time. Adding or subtracting such an interval to
84wxDateTime is always well-defined and is a fast operation.
85
86But in the daily life other, calendar-dependent time interval specifications are
87used. For example, 'one month later' is commonly used. However, it is clear
88that this is not the same as wxTimeSpan of 60*60*24*31 seconds because 'one
89month later' Feb 15 is Mar 15 and not Mar 17 or Mar 16 (depending on whether
90the year is leap or not).
91
92This is why there is another class for representing such intervals called
93wxDateSpan. It handles these sort of operations in the
94most natural way possible, but note that manipulating with intervals of
95this kind is not always well-defined. Consider, for example, Jan 31 + '1
96month': this will give Feb 28 (or 29), i.e. the last day of February and not
97the non-existent Feb 31. Of course, this is what is usually wanted, but you
98still might be surprised to notice that now subtracting back the same
99interval from Feb 28 will result in Jan 28 and @b not Jan 31 we started
100with!
101
102So, unless you plan to implement some kind of natural language parsing in the
103program, you should probably use wxTimeSpan instead of wxDateSpan (which is
104also more efficient). However, wxDateSpan may be very useful in situations
105when you do need to understand what 'in a month' means (of course, it is
106just @c wxDateTime::Now() + wxDateSpan::Month()).
107
108
109
110@section overview_datetime_arithmetics Date Arithmetics
111
112Many different operations may be performed with the dates, however not all of
113them make sense. For example, multiplying a date by a number is an invalid
114operation, even though multiplying either of the time span classes by a number
115is perfectly valid.
116
117Here is what can be done:
118
119@li @b Addition: a wxTimeSpan or wxDateSpan can be added to wxDateTime
120 resulting in a new wxDateTime object and also 2 objects of the same span class
121 can be added together giving another object of the same class.
122@li @b Subtraction: the same types of operations as above are
123 allowed and, additionally, a difference between two wxDateTime objects can be
124 taken and this will yield wxTimeSpan.
125@li @b Multiplication: a wxTimeSpan or wxDateSpan object can be
126 multiplied by an integer number resulting in an object of the same type.
127@li <b>Unary minus</b>: a wxTimeSpan or wxDateSpan object may finally be
128 negated giving an interval of the same magnitude but of opposite time
129 direction.
130
131For all these operations there are corresponding global (overloaded) operators
132and also member functions which are synonyms for them: Add(), Subtract() and
133Multiply(). Unary minus as well as composite assignment operations (like +=)
134are only implemented as members and Neg() is the synonym for unary minus.
135
136
137
138@section overview_datetime_timezones Time Zone Considerations
139
140Although the time is always stored internally in GMT, you will usually work in
141the local time zone. Because of this, all wxDateTime constructors and setters
142which take the broken down date assume that these values are for the local
143time zone. Thus, @c wxDateTime(1, wxDateTime::Jan, 1970) will not
144correspond to the wxDateTime Epoch unless you happen to live in the UK.
145All methods returning the date components (year, month, day, hour, minute,
146second...) will also return the correct values for the local time zone by
147default, so, generally, doing the natural things will lead to natural and
148correct results.
149
150If you only want to do this, you may safely skip the rest of this section.
151However, if you want to work with different time zones, you should read it to
152the end.
153
154In this (rare) case, you are still limited to the local time zone when
155constructing wxDateTime objects, i.e. there is no way to construct a
156wxDateTime corresponding to the given date in, say, Pacific Standard Time.
157To do it, you will need to call wxDateTime::ToTimezone or wxDateTime::MakeTimezone
158methods to adjust the date for the target time zone. There are also special
159versions of these functions wxDateTime::ToUTC and wxDateTime::MakeUTC for
160the most common case - when the date should be constructed in UTC.
161
162You also can just retrieve the value for some time zone without converting the
163object to it first. For this you may pass TimeZone argument to any of the
164methods which are affected by the time zone (all methods getting date
165components and the date formatting ones, for example). In particular, the
166Format() family of methods accepts a TimeZone parameter and this allows to
167simply print time in any time zone.
168
169To see how to do it, the last issue to address is how to construct a TimeZone
170object which must be passed to all these methods. First of all, you may construct
171it manually by specifying the time zone offset in seconds from GMT, but
172usually you will just use one of the @ref overview_datetime and
173let the conversion constructor do the job.
174
175I.e. you would just write
176
177@code
178wxDateTime dt(...whatever...);
179printf("The time is %s in local time zone", dt.FormatTime().c_str());
180printf("The time is %s in GMT", dt.FormatTime(wxDateTime::GMT).c_str());
181@endcode
182
183
184
185@section overview_datetime_dst Daylight Saving Time (DST)
186
187DST (a.k.a. 'summer time') handling is always a delicate task which is better
188left to the operating system which is supposed to be configured by the
189administrator to behave correctly. Unfortunately, when doing calculations with
190date outside of the range supported by the standard library, we are forced to
191deal with these issues ourselves.
192
193Several functions are provided to calculate the beginning and end of DST in
194the given year and to determine whether it is in effect at the given moment or
195not, but they should not be considered as absolutely correct because, first of
196all, they only work more or less correctly for only a handful of countries
197(any information about other ones appreciated!) and even for them the rules
198may perfectly well change in the future.
199
200The time zone handling methods (see @ref overview_datetime_timezones) use
201these functions too, so they are subject to the same limitations.
202
203
204
205@section overview_datetime_holidays wxDateTime and Holidays
206
207@todo WRITE THIS DOC PARAGRAPH.
208
209
210
211@section overview_datetime_compat Compatibility
212
213The old classes for date/time manipulations ported from wxWidgets version 1.xx
214are still included but are reimplemented in terms of wxDateTime. However, using
215them is strongly discouraged because they have a few quirks/bugs and were not
216'Y2K' compatible.
217
218*/
219