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

The only method I see which takes an epoch-style timestamp, so that I can convert it to something printable, is the SysTime constructor:

pure nothrow @safe this(long stdTime, immutable TimeZone tz = null);

According to the reference, this seems to take the value in hnsecs. My expectation would be that this means multiplying my initial value by 1_000_000. But if I do that, I get a random date 2500 years in the future.

I created this sample code:

void main() {
    long time = 1421865781342L;
    writefln("%s", SysTime(time));
    writefln("%s", SysTime(time * 10L));
    writefln("%s", SysTime(time * 100L));
    writefln("%s", SysTime(time * 1_000L));
    writefln("%s", SysTime(time * 10_000L));
    writefln("%s", SysTime(time * 100_000L));
    writefln("%s", SysTime(time * 1_000_000L));

    writefln("%s", Clock.currTime.stdTime);
}

Outputs:

0001-Jan-02 07:36:48.5781342
0001-Jan-17 03:04:47.781342
0001-Jun-14 05:44:39.81342
0005-Jul-04 08:23:20.1342
0046-Jan-21 10:50:03.342
0451-Jul-28 11:17:15.42
4506-Sep-18 16:42:14.2
635582516

My expectation would be that the final line would be something beginning with "14" at least. Playing around with possible multipliers, there doesn't even seem to be any integer value that would allow conversion between the timestamp I received and whatever SysTime expects.

I'm using:

DMD64 D Compiler v2.066.1
Ubuntu from .deb package

Is this a bug, or am I doing something wrong?

On 31/01/2015 11:18 a.m., 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
>
> The only method I see which takes an epoch-style timestamp, so that I
> can convert it to something printable, is the SysTime constructor:
>
> pure nothrow @safe this(long stdTime, immutable TimeZone tz = null);
>
> According to the reference, this seems to take the value in hnsecs. My
> expectation would be that this means multiplying my initial value by
> 1_000_000. But if I do that, I get a random date 2500 years in the future.
>
> I created this sample code:
>
> void main() {
>      long time = 1421865781342L;
>      writefln("%s", SysTime(time));
>      writefln("%s", SysTime(time * 10L));
>      writefln("%s", SysTime(time * 100L));
>      writefln("%s", SysTime(time * 1_000L));
>      writefln("%s", SysTime(time * 10_000L));
>      writefln("%s", SysTime(time * 100_000L));
>      writefln("%s", SysTime(time * 1_000_000L));
>
>      writefln("%s", Clock.currTime.stdTime);
> }
>
> Outputs:
>
> 0001-Jan-02 07:36:48.5781342
> 0001-Jan-17 03:04:47.781342
> 0001-Jun-14 05:44:39.81342
> 0005-Jul-04 08:23:20.1342
> 0046-Jan-21 10:50:03.342
> 0451-Jul-28 11:17:15.42
> 4506-Sep-18 16:42:14.2
> 635582516
>
> My expectation would be that the final line would be something beginning
> with "14" at least. Playing around with possible multipliers, there
> doesn't even seem to be any integer value that would allow conversion
> between the timestamp I received and whatever SysTime expects.
>
> I'm using:
>
> DMD64 D Compiler v2.066.1
> Ubuntu from .deb package
>
> Is this a bug, or am I doing something wrong?


On a slightly related note, I have code for UTC+0 to unix time stamp.
https://github.com/Devisualization/util/blob/b9ab5758e755c4e33832ac4aed0a5d7f2c728faf/source/core/devisualization/util/core/time.d

On Friday, 30 January 2015 at 22:22:27 UTC, Rikki Cattermole wrote:
> On a slightly related note, I have code for UTC+0 to unix time stamp.
> https://github.com/Devisualization/util/blob/b9ab5758e755c4e33832ac4aed0a5d7f2c728faf/source/core/devisualization/util/core/time.d

Unix timestamps can be negative, so you should probably be using longs instead of ulongs.

On Fri, 30 Jan 2015 22:38:20 +0000, Chris Williams wrote:

> Unix timestamps can be negative
WUT?! O_O

On 31/01/2015 12:06 p.m., ketmar wrote:
> On Fri, 30 Jan 2015 22:38:20 +0000, Chris Williams wrote:
>
>> Unix timestamps can be negative
> WUT?! O_O

Looks like we are both thinking the usual case.

The standard Unix time_t (data type representing a point in time) is a signed integer data type, traditionally of 32 bits (but see below), directly encoding the Unix time number as described in the preceding section. Being 32 bits means that it covers a range of about 136 years in total. The minimum representable time is 1901-12-13, and the maximum representable time is 2038-01-19. The second after 03:14:07 UTC 2038-01-19 this representation overflows. This milestone is anticipated with a mixture of amusement and dread; see year 2038 problem.

From wikipedia.

https://github.com/D-Programming-Language/druntime/blob/master/src/core/stdc/time.d#L68

Looks like I got to modify it.

On Friday, 30 January 2015 at 22:38:21 UTC, Chris Williams wrote:
> On Friday, 30 January 2015 at 22:22:27 UTC, Rikki Cattermole wrote:
>> On a slightly related note, I have code for UTC+0 to unix time stamp.
>> https://github.com/Devisualization/util/blob/b9ab5758e755c4e33832ac4aed0a5d7f2c728faf/source/core/devisualization/util/core/time.d
>
> Unix timestamps can be negative, so you should probably be using longs instead of ulongs.

Yup, there was a world before January 1st, 1970.

On Sat, 31 Jan 2015 12:12:08 +1300, Rikki Cattermole wrote:

> On 31/01/2015 12:06 p.m., ketmar wrote:
>> On Fri, 30 Jan 2015 22:38:20 +0000, Chris Williams wrote:
>>
>>> Unix timestamps can be negative
>> WUT?! O_O
> 
> Looks like we are both thinking the usual case.
> 
> The standard Unix time_t (data type representing a point in time) is a signed integer data type, traditionally of 32 bits (but see below), directly encoding the Unix time number as described in the preceding section. Being 32 bits means that it covers a range of about 136 years in total. The minimum representable time is 1901-12-13, and the maximum representable time is 2038-01-19. The second after 03:14:07 UTC 2038-01-19 this representation overflows. This milestone is anticipated with a mixture of amusement and dread; see year 2038 problem.
> 
>  From wikipedia.
> 
> https://github.com/D-Programming-Language/druntime/blob/master/src/core/
stdc/time.d#L68
> 
> Looks like I got to modify it.

nobody ever planned "negative timestamps". using signed time_t was just a design error (nobody cares at the time). unix timestamps are timestamps for things created in unix. i can't imagine how you can create something BEFORE the unix itself (hence 1970 as a starting point -- with some gap to allow older files).

there is no such thing as "negative timestamp", any negative timestamp is a bug.

On Fri, 30 Jan 2015 23:42:04 +0000, Chris Williams wrote:

> On Friday, 30 January 2015 at 22:38:21 UTC, Chris Williams wrote:
>> On Friday, 30 January 2015 at 22:22:27 UTC, Rikki Cattermole wrote:
>>> On a slightly related note, I have code for UTC+0 to unix time stamp. https://github.com/Devisualization/util/blob/
b9ab5758e755c4e33832ac4aed0a5d7f2c728faf/source/core/devisualization/util/ core/time.d
>>
>> Unix timestamps can be negative, so you should probably be using longs instead of ulongs.
> 
> Yup, there was a world before January 1st, 1970.

not for unix timestamps. please, stop that, unix timestamp was not designed to present any dates before 1970. "negative timestamp" is a bug in code.

On Friday, 30 January 2015 at 23:50:53 UTC, ketmar wrote:
> On Fri, 30 Jan 2015 23:42:04 +0000, Chris Williams wrote:
>
>> On Friday, 30 January 2015 at 22:38:21 UTC, Chris Williams wrote:
>>> On Friday, 30 January 2015 at 22:22:27 UTC, Rikki Cattermole wrote:
>>>> On a slightly related note, I have code for UTC+0 to unix time stamp.
>>>> https://github.com/Devisualization/util/blob/
> b9ab5758e755c4e33832ac4aed0a5d7f2c728faf/source/core/devisualization/util/
> core/time.d
>>>
>>> Unix timestamps can be negative, so you should probably be using longs
>>> instead of ulongs.
>> 
>> Yup, there was a world before January 1st, 1970.
>
> not for unix timestamps. please, stop that, unix timestamp was not
> designed to present any dates before 1970. "negative timestamp" is a bug
> in code.

Unless you know something I don't, everything I've ever read says that a negative unix timestamp is meant to refer to a time before 1970. It may not have been intentional, but since most database software probably stores birthdates (many of which are pre-1970) in this format, having a library be unable to support them just makes the library useless for many situations.

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