. .

. .

timestamp 1980-01-01T00:00:00

will brew UINT32 representing timestamp given

timestamp

will brew UINT32 representing current time

--------------------------------------------------

FASM already has the conversion routine, it's (strangely) in SYSTEM.INC - so one could move the conversion into ASSEMBLE.INC and keep only peek_timestamp in SYSTEM.INC. Alternatively timestamp32 and timestamp64 to brew 32-bit or 64-bit timestamps.

EDIT : only subject

Why restrict yourself to only one timestamp possibility? And which timestamp format standard would you suggest following anyway?

I would suggest instead that you can use a macro for both of these operations and it would give you the flexibility to implement any of the integer coding standards you require.

BTW: I trust you did not forget about %t.

DOS386 wrote:

FASM already has the conversion routine, it's (strangely) in SYSTEM.INC

That should not be strange considering that it is a documented part of fasm's OS abstraction interface. In my abandoned attempt to document fasm's internals I managed to at least document the fasm's interface (which is a useful information for the purpose of porting fasm to a new OS) and there you can find section about timestamp:

The [unfinished] official guide to flat assembler internals, section 2.6 wrote:

The "make_timestamp" routine should return the valid timestamp in the EAX. This value should contain current system time converted to the number of seconds since the 1-1-1970 00:00:00 (some operating systems already use the timestamp format for the system time, so the conversion is not needed there).

And what you get with "%t" symbol during the assembly is exactly the value returned by this routine.

Actually "%t" seems to cover most of this issue, except:

* 64-bit timestamps
* Other-than-now timestamps ("%t=1980-01-01T00:00:00" ???)

> not be strange considering that it is a
> documented part of fasm's OS abstraction interface

OK ... one could just split the "6-to-1" conversion from "peek-6-from-the-OS", as it would be needed for other-than-now timestamps.

AFAIK 32-bit timestamps will die in 2038:

There is no reason that %t cannot return a 64-bit value in the future. It might be 32-bit today, but tomorrow ...?

But having the very same "%t" returning 64-bit instead of 32-bit will break things (or would break if anyone used it ...).

Why? So far %t has always returned a positive number less than 31-bit. %t can continue to return a positive number after April 2038. Where is the problem?

> Where is the problem?

In C and C+++ compilers. "int" is unknown size (used to be usually 32-bit) and usually signed. Set your clock to 2040 and enjoy various apps crashing

fasm != C or C+++ [sic], thankfully.

Well, I set my clock to 2050 and assembled:

Code:

dq %t

I happily got unsigned value.

Bonus points to anyone that implements a macro to do full conversion to and from RFC2550 and a full 64-bit signed %t value.