__TIMESTAMP__ is pretty useless:
`string literal of the date and time of compilation "www mmm dd hh:mm:ss yyyy"`
eg:Wed Jan 24 11:03:56 2018
which is a weird non-standard format not understood by std.datetime.
__DATE__ and __TIME__ are also pretty useless.

Could we have __TIMESTAMP_UNIXEPOCH__ (or perhaps
__TIMESTAMP_SYSTIME__ to get a SysTime) ?

from that, users can convert to whatever format they want.

On 24/01/2018 7:18 PM, Timothee Cour wrote:
> __TIMESTAMP__ is pretty useless:
> `string literal of the date and time of compilation "www mmm dd hh:mm:ss yyyy"`
> eg:Wed Jan 24 11:03:56 2018
> which is a weird non-standard format not understood by std.datetime.
> __DATE__ and __TIME__ are also pretty useless.
> 
> Could we have __TIMESTAMP_UNIXEPOCH__ (or perhaps
> __TIMESTAMP_SYSTIME__ to get a SysTime) ?

That can be a library solution from __TIMESTAMP__.

On Wed, Jan 24, 2018 at 5:50 PM, rikki cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 24/01/2018 7:18 PM, Timothee Cour wrote:
>>
>> __TIMESTAMP__ is pretty useless:
>> `string literal of the date and time of compilation "www mmm dd hh:mm:ss
>> yyyy"`
>> eg:Wed Jan 24 11:03:56 2018
>> which is a weird non-standard format not understood by std.datetime.
>> __DATE__ and __TIME__ are also pretty useless.
>>
>> Could we have __TIMESTAMP_UNIXEPOCH__ (or perhaps
>> __TIMESTAMP_SYSTIME__ to get a SysTime) ?
>
>
> That can be a library solution from __TIMESTAMP__.

no, there's missing time zone information, so we can't reconstruct unix epoch nor utc time

On Wednesday, January 24, 2018 18:25:21 Timothee Cour via Digitalmars-d wrote:
> On Wed, Jan 24, 2018 at 5:50 PM, rikki cattermole via Digitalmars-d
>
> <digitalmars-d@puremagic.com> wrote:
> > On 24/01/2018 7:18 PM, Timothee Cour wrote:
> >> __TIMESTAMP__ is pretty useless:
> >> `string literal of the date and time of compilation "www mmm dd
> >> hh:mm:ss
> >> yyyy"`
> >> eg:Wed Jan 24 11:03:56 2018
> >> which is a weird non-standard format not understood by std.datetime.
> >> __DATE__ and __TIME__ are also pretty useless.
> >>
> >> Could we have __TIMESTAMP_UNIXEPOCH__ (or perhaps
> >> __TIMESTAMP_SYSTIME__ to get a SysTime) ?
> >
> > That can be a library solution from __TIMESTAMP__.
>
> no, there's missing time zone information, so we can't reconstruct unix epoch nor utc time

Yeah, and since getting that information requires calling C functions that can't be called during CTFE, you can't interpret the value at compile time - which is the only time that you're guaranteed that the system running the code has the same timezone as when __TIMESTAMP__ was intepreted. Either __TIMESTAMP__ would need to be changed (which I doubt Walter would allow for fear of something relying on the format), or we'd need something like __TIMESTAMP_UNIXTIME__ or whatever.

The only viable alternative that I can think of at the moment is to pass the information to the program as part of the build. But all in all, I think that __TIMESTAMP__ is pretty useless as-is unless you just want a ballpark date and time for when the build was generated and don't care what format it's in.

In most cases, I'd argue that it's better not to have anything like __TIMESTAMP__, because then the build is guaranteed to not be reproducible, but presumably you found some use for it, since you're looking for a version of __TIMESTAMP__ that's in a more standard format.

- Jonathan M Davis

On 1/24/2018 11:18 AM, Timothee Cour wrote:
> __TIMESTAMP__ is pretty useless:
> `string literal of the date and time of compilation "www mmm dd hh:mm:ss yyyy"`
> eg:Wed Jan 24 11:03:56 2018
> which is a weird non-standard format not understood by std.datetime.

It's the format emitted by the Standard C library function asctime():

    http://pubs.opengroup.org/onlinepubs/009695399/functions/asctime.html

> __DATE__ and __TIME__ are also pretty useless.

These also match the format of the Standard C preprocessor macros __DATE__ and __TIME__.

On 1/25/18 4:39 AM, Walter Bright wrote:
> On 1/24/2018 11:18 AM, Timothee Cour wrote:
>> __TIMESTAMP__ is pretty useless:
>> `string literal of the date and time of compilation "www mmm dd hh:mm:ss yyyy"`
>> eg:Wed Jan 24 11:03:56 2018
>> which is a weird non-standard format not understood by std.datetime.
> 
> It's the format emitted by the Standard C library function asctime():
> 
>      http://pubs.opengroup.org/onlinepubs/009695399/functions/asctime.html
> 
>> __DATE__ and __TIME__ are also pretty useless.
> 
> These also match the format of the Standard C preprocessor macros __DATE__ and __TIME__.

We should support __ISOTIMESTAMP__ which is readable by std.datetime [1].

The compiler is in D after all, we can use it! Or at least, port enough of std.datetime to display it :)

-Steve

[1] https://dlang.org/phobos/std_datetime_systime.html#.SysTime.toISOExtString

Just a numeric (long) result from `time` - more compact storage and simpler implementation.

On 1/27/18 4:05 AM, Kagamin wrote:
> Just a numeric (long) result from `time` - more compact storage and simpler implementation.

A numeric value is fine, but I would be cautious about relying on time(). It's not guaranteed to return 64 bits, meaning the y2k35 bug would affect D ;)

However, having a nice actual timestamp string may be more useful. My suggestion also contains the timezone, so it has more info (and this was a further request by the OP).

-Steve