Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#14776 closed defect (fixed)

wxDateTime <-> time_t problem fix

Reported by: troelsk Owned by:
Priority: normal Milestone:
Component: base Version: stable-latest
Keywords: wxDateTime Cc:
Blocked By: Blocking:
Patch: yes


It is unexpected that a bad time_t value produce a valid wxDateTime instance, IsValid() returning true.
Patch: Fix it

Attachments (2)

invalid_time_t.patch download (725 bytes) - added by troelsk 6 years ago.
invalid_time_t_2.patch download (3.6 KB) - added by troelsk 6 years ago.

Download all attachments as: .zip

Change History (7)

Changed 6 years ago by troelsk


comment:1 Changed 6 years ago by VZ

  • Resolution set to fixed
  • Status changed from new to closed

(In [72750]) Make wxDateTime invalid after Set((time_t)-1) call.

Closes #14776.

comment:2 Changed 6 years ago by troelsk

It is unusual to code the abnormal case first but whatever suits you.
In any case, the magic number with the cast is rather ugly, see additional patch.

Changed 6 years ago by troelsk


comment:3 Changed 6 years ago by vadz

Sorry, I don't like this name (if really pressed, I'd probably call it wxInvalidTimeT or something like this) but more than this, I really don't see the point. (time_t)-1 is a very well known constant, it's in ANSI C and POSIX and so on. And it's not even part of public wx API, so why should we bother defining a name for it?

comment:4 Changed 6 years ago by troelsk

Casts are ugly and better avoided or so I thought. Also, it is too easy to forget the darned cast, as I did in this patch. Moreover, obviously CRT should provide a literal constant, #define TIME_ERR (time_t)-1, but since it does not it would be considerate of wx to plug this hole (unless plugging such holes is considered out of scope).

comment:5 Changed 6 years ago by vadz

In general I agree but this is so minor and, again, so widespread that I really don't think we should care about it. Anybody who does care already has a define in their own code (which they can happily use). And those who don't won't start using it just because we add another constant. Again, this is not part of wx API, so why should we care about it? And where would we stop if we did?

Note: See TracTickets for help on using tickets.