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