correction for Mac OS compilation

[wxWidgets.git] / docs / latex / wx / tdate.tex

diff --git a/docs/latex/wx/tdate.tex b/docs/latex/wx/tdate.tex
index fa232d914da6bd7f5f646cf409313bf902b71b0a..9dfef5b2b7f693f114ac39bf1a4aae7cf5a3eb96 100644 (file)
--- a/docs/latex/wx/tdate.tex
+++ b/docs/latex/wx/tdate.tex
@@ -6,12 +6,12 @@
 %% Created:     07.03.00
 %% RCS-ID:      $Id$
 %% Copyright:   (c) Vadim Zeitlin
-%% Licence:     wxWindows licence
+%% License:     wxWindows license
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \section{Date and time classes overview}\label{wxdatetimeoverview}
 
-Classes: \helpref{wxDateTime}{wxdatetime}, \helpref{wxDateSpan}{wxdatespan}, \helpref{wxTimeSpan}, \helpref{wxtimespan}, \helpref{wxCalendarCtrl}{wxcalendarctrl}
+Classes: \helpref{wxDateTime}{wxdatetime}, \helpref{wxDateSpan}{wxdatespan}, \helpref{wxTimeSpan}{wxtimespan}, \helpref{wxCalendarCtrl}{wxcalendarctrl}
 
 \subsection{Introduction}
 
@@ -20,15 +20,15 @@ of the supported features of \helpref{wxDateTime}{wxdatetime} class are:
 
 \twocolwidtha{7cm}
 \begin{twocollist}\itemsep=0pt
-\item{Wide range}{The range of supported dates goes from about 4714 B.C. to
+\twocolitem{Wide range}{The range of supported dates goes from about 4714 B.C. to
 some 480 million years in the future.}
-\item{Precision}{Not using floating point calculations anywhere ensures that
+\twocolitem{Precision}{Not using floating point calculations anywhere ensures that
 the date calculations don't suffer from rounding errors.}
-\item{Many features}{Not only all usual calculations with dates are supported,
+\twocolitem{Many features}{Not only all usual calculations with dates are supported,
 but also more exotic week and year day calculations, work day testing, standard
 astronomical functions, conversion to and from strings in either strict or free
 format.}
-\item{Efficiency}{Objects of wxDateTime are small (8 bytes) and working with
+\twocolitem{Efficiency}{Objects of wxDateTime are small (8 bytes) and working with
 them is fast}
 \end{twocollist}
 
@@ -44,7 +44,8 @@ There are also helper classes which are used together with wxDateTime:
 \helpref{wxDateTimeHolidayAuthority}{wxdatetimeholidayauthority} which is used
 to determine whether a given date is a holiday or not and 
 \helpref{wxDateTimeWorkDays}{wxdatetimeworkdays} which is a derivation of this
-class for which (only) Saturdays and Sundays are the holidays.
+class for which (only) Saturdays and Sundays are the holidays. See more about
+these classes in the discussion of the \helpref{holidays}{tdateholidays}.
 
 Finally, in other parts of this manual you may find mentions of wxDate and
 wxTime classes. \helpref{These classes}{tdatecompatibility} are obsolete and
@@ -110,7 +111,7 @@ also more efficient). However, wxDateSpan may be very useful in situations
 when you do need to understand what does `in a month' mean (of course, it is
 just {\tt wxDateTime::Now() + wxDateSpan::Month()}).
 
-\subsection{Date arithmetics}
+\subsection{Date arithmetics}\label{tdatearithm}
 
 Many different operations may be performed with the dates, however not all of
 them make sense. For example, multiplying date by a number is an invalid
@@ -119,7 +120,7 @@ perfectly valid.
 
 Here is what can be done:
 
-\begin{twocollist}
+\begin{twocollist}\itemsep=0pt
 \item{{\bf Addition}}{a wxTimeSpan or wxDateSpan can be added to wxDateTime
 resulting in a new wxDateTime object and also 2 objects of the same span class
 can be added together giving another object of the smae class.}
@@ -174,9 +175,9 @@ 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 \helpref{symbolic time zone
-names}{wxdatetimetimezones} and let the conversion constructor do the job.
-I.e.. you would just write
+usually you will just use one of the \helpref{symbolic time zone names}{wxdatetime} and
+let the conversion constructor do the job.
+I.e. you would just write
 
 \begin{verbatim}
 wxDateTime dt(...whatever...);
@@ -184,7 +185,7 @@ 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());
 \end{verbatim}
 
-\subsection{Daylight saving time (DST)}
+\subsection{Daylight saving time (DST)}\label{tdatedst}
 
 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
@@ -204,9 +205,14 @@ too, so they are subject to the same limitations.
 
 % is this really needed? \subsection{Conversion to/from text}
 
+\subsection{wxDateTime and Holidays}\label{tdateholidays}
+
+TODO.
+
 \subsection{Compatibility}\label{tdatecompatibility}
 
 The old classes for date/time manipulations ported from wxWindows 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.
+