getting current DateTime

[Jonathan M Davis via Digitalmars-d-learn]

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