www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - getting current DateTime

reply "bitwise" <bitwise.pvt gmail.com> writes:
How do you get the current DateTime?
Why doesn't DateTime have DateTime.now?
Dec 30 2014
next sibling parent "FrankLike" <1150015857 qq.com> writes:
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
Dec 30 2014
prev sibling parent reply ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
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 =3D cast(DateTime)Clock.currTime;
Dec 30 2014
parent reply "bitwise" <bitwise.pvt gmail.com> writes:
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
Dec 30 2014
parent reply "bitwise" <bitwise.pvt gmail.com> writes:
 It would be nice if that cast was made implicit though.


Just realizing now that DateTime doesn't have sub-second accuracy 
=/
Dec 30 2014
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Dec 31 2014
parent reply "bitwise" <bitwise.pvt gmail.com> writes:
 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 

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."
Dec 31 2014
parent reply Jonathan M Davis via Digitalmars-d-learn writes:
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

 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
Jan 02 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Jan 02 2015
parent Jonathan M Davis via Digitalmars-d-learn writes:
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
Jan 02 2015