wxDateTime

wxDateTime class represents an absolute moment in time.

The type wxDateTime_t is typedefed as unsigned short and is used to contain the number of years, hours, minutes, seconds and milliseconds.

Global constant wxDefaultDateTime and synonym for it wxInvalidDateTime are defined. This constant will be different from any valid wxDateTime object.

Datelight Savings Time tips

Some care must be taken while doing things like "stepping through" the calendar if you are in a locale that uses Daylight Savings Time (DST). Consider this code example:

 wxDateTime datetime = wxDateTime::Today();
 datetime.SetYear(2004);
 datetime.SetMonth(wxDateTime::Oct);
 datetime.SetDay(31);
 // Current value: "10/31/04 00:00:00"
 datetime += wxTimeSpan::Day();
 // Current value: "10/31/04 23:00:00" in locale that respects DST; "11/01/04 00:00:00" elsewhere

I thought this was a bug for awhile until it was pointed out to me that Oct 31 is the time daylight savings ends this year. There are a couple of solutions. You could check the results of wxDateTime::GetBeginDST() and wxDateTime::GetEndDST() and manually auto "correct" but the more accurate solution is to simply use a wxDateSpan instead of a wxTimeSpan.

Careful with Nasty TimeZone Bite

The documentation and datetime.h tell it's safe to write GMT0 + offset to specify a time zone if abs(offset) <= 12. It is not. At least under VS.Net the following code will not work:

  int nOffset = 3;
  return wxDateTime::Today().Format(wxDefaultDateTimeFormat,wxDateTime::GMT0 + nOffset);

The reason is that wxDateTime::GMT0+nOffset has a type int, not wxDateTime::TZ; this will call the constructor for the TimeZone object that uses number of seconds (rather than the TZ scalar), so you'll end up with an incorrect result. The correct construction is to use a static cast to force the argument to be taken as a TZ value:

  return wxDateTime::Today().Format(wxDefaultDateTimeFormat,(wxDateTime::TZ)(wxDateTime::GMT0 + nOffset));

See Also

• Trunk Documentation
• Stable Documentation