On Friday, January 02, 2015 08:31:11 Steven Schveighoffer via Digitalmars-d-learn wrote: > On 1/2/15 6:21 AM, Jonathan M Davis via Digitalmars-d-learn wrote: > > > The main places that code is likely to use DateTime is if it needs to > > operate on dates and times separately from any connection to the system's > > time or time zones and when you want to get the separate pieces of the > > date and time (year, month, etc.) efficiently, because converting to > > DateTime calculates that information once, whereas calling each individual > > property on SysTime results in having to do some of the calculations > > multiple times if you want to access multiple of the properties (which > > sometimes makes me think that I never should have put those properties on > > SysTime in the first place, but it's convenient if you don't care about the > > small loss of efficiency when duplicating some of the calculations to get > > multiple of the properties or you only need one or two of the properties). > > Not sure if you saw it, but I think a question for you Jonathan, is why > DateTime ignores subsecond data? Wouldn't it be trivial to include that too? > > It seems to be a conflict to say, either I want to efficiently work with > components, or I want subsecond resolution. Even if subseconds was a > single value to deal with (like a Duration).
It could be added, but IIRC, I decided that it didn't make sense, because the primary reason for DateTime was for calendar-based operations, and subsecond resolution doesn't make any sense for those. Those only make sense for when you're dealing with the actual system time. They _do_ make some sense when using DateTime strictly for holding the separate pieces of the date/time rather than accessing each of the properties on SysTime directly, but it's also cheaper to get the subseconds than any of the properties that DateTime currently holds. > I personally have not used DateTime, as SysTime fits my needs quite well. For most situations, it's what you need, since most code isn't looking to deal with dates and times without tying them to the system time and time zone somehow. Regardless of my original intentions, I think that the primary use case for DateTime, Date, and TimeOfDay has ended up simply being to hold those properties for SysTime rather than calculating each of them individually. But they'll still come in handy for anyone who actually needs to be able to do date/time calculations for calendar stuff without getting time zones and whatnot involved. - Jonathan M Davis
