Download Reference Manual
The Developer's Library for D
About Wiki Forums Source Search Contact

Ticket #779 (closed defect: wontfix)

Opened 12 years ago

Last modified 12 years ago

DateTime should initialize to 0000-00-00, not 0001-01-01

Reported by: Deewiant Assigned to: schveiguy
Priority: major Milestone:
Component: Core Functionality Version: trunk
Keywords: Cc:

Description

DateTime? currently initializes to 0001-01-01---or rather, DateTime?.splitDate adds 1 to each of year, month, and day, on access. This is somewhat problematic.

Say that you have a DateTime? with only a relevant time component, for instance 23:00. You then add 2 hours to this time, resulting in a DateTime? of 0001-01-02 01:00. The result makes sense---the day after 0001-01-01 is 0001-01-02---but it's not intuitive. Accessing the day component of the DateTime? would now return 2, but the offset from the original time is 1. It's a catch one has to be aware of, and there's no good reason for it.

Another thing is that DateTime?.init is currently a valid value for DateTime?. Given date-parsing code, for instance, one can't be sure whether a date field was parsed correctly as 1 or whether it's merely the initial value. It's somewhat analogous to having NaN be the initializer for floating point types. There's no such thing as an uninitialized DateTime?, but there's no reason why there shouldn't be.

I'm not sure if changing DateTime?.splitDate to merely not add the 1 to the date components would be safe, as I'm not fully familiar with the DateTime? internals. It seems to be the simplest solution to this, though.

Change History

11/26/07 18:26:18 changed by schveiguy

  • status changed from new to assigned.

Since DateTime? is a linear value and not a field-oriented structure, it does not make sense that a DateTime? has ONLY a time value in it, and not a Date value. However it may make sense that DateTime? should have a nan value. Perhaps something like DateTime?(long.min)?

12/06/07 15:08:48 changed by schveiguy

The calendar functionality has been deprecated in Time (the name was changed from DateTime). This includes the splitDate function, and the notion that Time contains a specific year, month, or day. Therefore, the first issue is moot.

12/10/07 05:44:59 changed by schveiguy

  • status changed from assigned to closed.
  • resolution set to wontfix.

While having a 'nan' value for Time is possible, as there is a valid range of time from 10000 BC to 10000 AD, there is a question of whether the operators should behave similar to say the floating point operators. For example, should opEquals return 0 if nan is compared to any other value? In this case, all of the operators would have to check for nan, which seems like a lot of extra calculations that would normally not be needed, just so we could have a 'nan' value.

Furthermore, there is nothing saying that min and max cannot be extended to long.min and long.max, which means no invalid dates are possible.

If you are having trouble parsing a date, can't you just throw an exception instead?

I can't see a good reason to have a 'nan' value.