How do you get the current DateTime?
Why doesn't DateTime have DateTime.now?

On Wednesday, 31 December 2014 at 06:03:06 UTC, bitwise wrote:
> How do you get the current DateTime?
> Why doesn't DateTime have DateTime.now?

import std.stdio;
import std.datetime;
void main()
{
	writeln(Clock.currTime);
}


Frank

On Wed, 31 Dec 2014 06:03:04 +0000
bitwise via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
wrote:

> How do you get the current DateTime?
> Why doesn't DateTime have DateTime.now?
but it has! ;-)

auto now = cast(DateTime)Clock.currTime;

On Wednesday, 31 December 2014 at 06:31:13 UTC, ketmar via Digitalmars-d-learn wrote:
> On Wed, 31 Dec 2014 06:03:04 +0000
> bitwise via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
> wrote:
>
>> How do you get the current DateTime?
>> Why doesn't DateTime have DateTime.now?
> but it has! ;-)
>
> auto now = cast(DateTime)Clock.currTime;

Ah! indeed it does.

It would be nice if that cast was made implicit though.

Thanks =D

> It would be nice if that cast was made implicit though.

Just realizing now that DateTime doesn't have sub-second accuracy =/

On 12/31/14 1:41 AM, bitwise wrote:
>> It would be nice if that cast was made implicit though.
>
> Just realizing now that DateTime doesn't have sub-second accuracy =/

Why do you need DateTime and not SysTime?

I'm actually surprised it doesn't have that too...

-Steve

> Why do you need DateTime and not SysTime?
>
> I'm actually surprised it doesn't have that too...
>
> -Steve

Initially I was looking for something that would be the equivalent to DateTime in C#. This now appears to be SysTime, not DateTime in D.

It seems the only real reason to use DateTime is as an optimization.

From DateTime docs:
"It is optimized for calendar-based operations and has no concept of time zone."

On Wednesday, December 31, 2014 19:07:13 bitwise via Digitalmars-d-learn wrote:
> > Why do you need DateTime and not SysTime?
> >
> > I'm actually surprised it doesn't have that too...
> >
> > -Steve
>
> Initially I was looking for something that would be the equivalent to DateTime in C#. This now appears to be SysTime, not DateTime in D.
>
> It seems the only real reason to use DateTime is as an optimization.
>
>  From DateTime docs:
> "It is optimized for calendar-based operations and has no concept
> of time zone."

That and it gets used internally by SysTime for any calendar-based operations that it has to do, so it encapsulates that functionality, but if what you're looking for is something that represents the time from the system rather than a date and time on a calendar, you want SysTime.

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).

- Jonathan M Davis

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).

I personally have not used DateTime, as SysTime fits my needs quite well.

-Steve

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