On Sat, 31 Jan 2015 00:03:43 +0000, Chris Williams wrote:

> since most database software probably
> stores birthdates (many of which are pre-1970) in this format
O_O
a perfectly broken software.

On Saturday, 31 January 2015 at 00:20:07 UTC, ketmar wrote:
> On Sat, 31 Jan 2015 00:03:43 +0000, Chris Williams wrote:
>
>> since most database software probably
>> stores birthdates (many of which are pre-1970) in this format
> O_O
> a perfectly broken software.

And stdc:

http://h50146.www5.hp.com/products/software/oe/tru64unix/manual/v51a_ref/HTML/MAN/MAN3/3955____.HTM

And UNIX:

http://www.lehman.cuny.edu/cgi-bin/man-cgi?mktime+3

On Saturday, 31 January 2015 at 00:14:37 UTC, Steven Schveighoffer wrote:
> On 1/30/15 5:18 PM, Chris Williams wrote:
>> I'm attempting to print a human-readable version of a timestamp. The
>> timestamp is coming from an external service, via JSON. An example is:
>>
>> 1421865781342
>>
>> Which I know to be:
>>
>> 2015-01-21T18:43:01.342Z
>>
>
> http://dlang.org/phobos/std_datetime.html#.unixTimeToStdTime
>
> It's kind of convoluted because there is no epoch, but you can make one:
>
> import std.datetime;
> import std.stdio;
>
> void main(string[] args)
> {
>     // can't make this enum because of time zone...
>     auto epoch = SysTime(unixTimeToStdTime(0), UTC());
>     writeln(epoch + 1_421_865_781_342.msecs);
> }
>
> output:
> 2015-Jan-21 18:43:01.342Z
>
> Note the reason your code didn't work is because SysTime uses 1/1/1 as the epoch.
>
> -Steve

D'oh, I missed that in the description:

"and convert it to hnsecs in UTC since midnight, January 1st, 1 A.D. UTC"

That does explain it. I also didn't spot the declaration of unixTimeToStdTime(), which assuredly helps.

Thank you!

On Friday, January 30, 2015 19:14:37 Steven Schveighoffer via Digitalmars-d-learn wrote:
> On 1/30/15 5:18 PM, Chris Williams wrote:
> > I'm attempting to print a human-readable version of a timestamp. The timestamp is coming from an external service, via JSON. An example is:
> >
> > 1421865781342
> >
> > Which I know to be:
> >
> > 2015-01-21T18:43:01.342Z
> >
>
> http://dlang.org/phobos/std_datetime.html#.unixTimeToStdTime
>
> It's kind of convoluted because there is no epoch, but you can make one:
>
> import std.datetime;
> import std.stdio;
>
> void main(string[] args)
> {
>      // can't make this enum because of time zone...
>      auto epoch = SysTime(unixTimeToStdTime(0), UTC());
>      writeln(epoch + 1_421_865_781_342.msecs);
> }
>
> output:
> 2015-Jan-21 18:43:01.342Z
>
> Note the reason your code didn't work is because SysTime uses 1/1/1 as the epoch.

Yeah. I really should add a unixTimeToSysTime function, but when I originally wrote std.datetime, I wasn't thinking about getting times from C stuff and converting them to D, just the other way around (a stupid oversight in retrospect). The functionality is there, but it's more convoluted than it should be. And the term "std time" was stupid on my part too, since there's nothing standard about it except that it uses midnight of 1/1/1 as the epoch like the ISO standard says (but that has nothing to do with hnsecs). Oh well, too late now, and I still don't know what a good name for it would have been.

I'll have to put adding unixTimeToSysTime on the list of things to do after finish splitting std.datetime (which I started again the other day but is going more slowly than I'd like, since I've been rather busy). I also need to update the "Introduction to std.datetime" article so that it talks more about stuff like that than the now defunct std.date. When Walter was dealing with some of that recently, he thought that it should focus more on interacting with C than std.date, which makes sense at this point (though, since he was porting something old from std.date, it's current state was presumably useful to him).

Too much to do, too little time...

- Jonathan M Davis

On Friday, January 30, 2015 22:03:02 Jonathan M Davis via Digitalmars-d-learn wrote:
> Yeah. I really should add a unixTimeToSysTime function,

Actually, maybe it should be a static function on SysTime called fromUnixTime to go with toUnixTime. I don't know. Regardless, it's a nicety that should be there, and I botched things by not having it.

- Jonathan M Davis

On 1/31/15 1:07 AM, Jonathan M Davis via Digitalmars-d-learn wrote:
> On Friday, January 30, 2015 22:03:02 Jonathan M Davis via Digitalmars-d-learn wrote:
>> Yeah. I really should add a unixTimeToSysTime function,
>
> Actually, maybe it should be a static function on SysTime called
> fromUnixTime to go with toUnixTime. I don't know. Regardless, it's a nicety
> that should be there, and I botched things by not having it.

Might I suggest that you simply define an enum for UnixEpoch that's a SysTime. Then you can do whatever you want.

Note that unixTimeToSysTime doesn't help the OP, his timestamp is in milliseconds since 1/1/1970.

-Steve

On Monday, February 02, 2015 08:49:58 Steven Schveighoffer via Digitalmars-d-learn wrote:
> On 1/31/15 1:07 AM, Jonathan M Davis via Digitalmars-d-learn wrote:
> > On Friday, January 30, 2015 22:03:02 Jonathan M Davis via Digitalmars-d-learn wrote:
> >> Yeah. I really should add a unixTimeToSysTime function,
> >
> > Actually, maybe it should be a static function on SysTime called fromUnixTime to go with toUnixTime. I don't know. Regardless, it's a nicety that should be there, and I botched things by not having it.
>
> Might I suggest that you simply define an enum for UnixEpoch that's a SysTime. Then you can do whatever you want.
>
> Note that unixTimeToSysTime doesn't help the OP, his timestamp is in milliseconds since 1/1/1970.

Then I should probably just do both - declare a function to do the conversion (since that's more user-friendly for the common case) and supply an enum for the unix epoch if someone is converting to something like milliseconds instead of seconds for the unix epoch.

- Jonathan M Davis

On 2/2/15 10:06 AM, Jonathan M Davis via Digitalmars-d-learn wrote:
> On Monday, February 02, 2015 08:49:58 Steven Schveighoffer via Digitalmars-d-learn wrote:
>> On 1/31/15 1:07 AM, Jonathan M Davis via Digitalmars-d-learn wrote:
>>> On Friday, January 30, 2015 22:03:02 Jonathan M Davis via Digitalmars-d-learn wrote:
>>>> Yeah. I really should add a unixTimeToSysTime function,
>>>
>>> Actually, maybe it should be a static function on SysTime called
>>> fromUnixTime to go with toUnixTime. I don't know. Regardless, it's a nicety
>>> that should be there, and I botched things by not having it.
>>
>> Might I suggest that you simply define an enum for UnixEpoch that's a
>> SysTime. Then you can do whatever you want.
>>
>> Note that unixTimeToSysTime doesn't help the OP, his timestamp is in
>> milliseconds since 1/1/1970.
>
> Then I should probably just do both - declare a function to do the
> conversion (since that's more user-friendly for the common case) and supply
> an enum for the unix epoch if someone is converting to something like
> milliseconds instead of seconds for the unix epoch.

You already have various unixTimeToXXX functions, so it's probably moot, but with an epoch, such operations are dead simple:

auto t = UnixEpoch + time().seconds;

I see very little value in a wrapper function to do this. But it's already there, so...

BTW, I think with UFCS, having the 'seconds' etc. functions is one of the coolest parts of D's time library. I love that part :)

-Steve

>>> Might I suggest that you simply define an enum for UnixEpoch that's a
>>> SysTime. Then you can do whatever you want.

ping on this.