Problems with predicate get_time

Help!
,
#1

Hello everyone!

Faced the following problem. We use the 32-bit version of SWI-prolog on windows 10 64-bit and with this combination, the predicate get_time() does not work correctly. Ultimately the result is always “Sun 00 Jan 00: 00: 00”.
Has anyone encountered such a problem?
Are there any options how to solve this problem?

#2

@tata_g I use Linux, so not sure if this changes on Windows, but get_time (-TimeStamp) gives me the number of seconds since the start of 1970.

?- get_time(Now).
Now = 1575792862.8043513.

Converting that to something human readable requires stamp_date_time (+TimeStamp, -DateTime, +TimeZone)

?- get_time(Now), 
stamp_date_time(Now, 
                date(Year, Month, Day, Hour, Minute, Second, 
                     UTCOffset, TimeZone, Y), 
                'UTC').
Now = 1575792887.7244942,
Year = 2019,
Month = 12,
Day = Hour, Hour = 8,
Minute = 14,
Second = 47.724494218,
UTCOffset = 0,
TimeZone = 'UTC',
Y =  (-).

If you are getting all zeroes, it could be the hardware clock on your computer isn’t set correctly. What does Windows say the time is?

#3

Hardware clock on my computer set correctly. The Windows say that the time is right.

#4

Looks like a bug. Do others experience the same? Can you use the 64-bit version? There isn’t much reason to use the 32-bit version unless you need to link to 32-bit DLLs or you have less than 2 Gb memory.

#5

Win 10 1809 [17763.107] 64bit:

Welcome to SWI-Prolog (threaded, 32 bits, version 8.1.17)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
Please run ?- license. for legal details.

For online help and background, visit https://www.swi-prolog.org
For built-in help, use ?- help(Topic). or ?- apropos(Word).

?- get_time(X).
X = 9.568903683405649e+17.
#6

Definitely a bug. As @jan suggested, probably the easiest fix is to try the 64 bit version.

?- stamp_date_time(9.568903683405649e+17, date(Year, Month, Day, Hour, Minute, Second, UTCOffs
Year = 30322650632,
Month = 1,
Day = 12,
Hour = 17,
Minute = 21,
Second = 4.0,
UTCOffset = 0,
TimeZone = 'UTC',
Y =  (-).

If it’s not a bug, your hardware clock is set well into 30-billion AD.

#7

LOL, now I’m even further in future:

get_time(X), stamp_date_time(X, Dt, 'UTC').
X = 1.0061325978859355e+18,
Dt = date(1818303695, 8, 3, 9, 38, 8.0, 0, 'UTC', -).

(should’ve tried converting it, in the end i thought “nonzero is OK” - even though i paused thinking “1.xxx_e17 is a pretty big number”, …)

Probably a bug, Windows believe it’s the current year.

#8

We need to use exactly this configuration (Windows 64-bit and SWI-prolog 32-bit). The fact is that we write client-server applications on SWI-prolog. And we could just use a 64-bit SWI-prolog for the server. But our client applications run on 32-bit systems. So for cross-platform compatibility, we need a 32-bit SWI-prolog that will work on both 32-bit and 64-bit systems. Prior to this situation, there were no compatibility issues with other predicates. But now we are faced with this problem. This is fundamentally important for us.

#9

I wouldn’t know why a 64 bit server cannot talk to a 32-bit client as SWI-Prolog is supposed to be fully compatible except that the 64 bit version can address more memory. Well, .qlf files and saved states are compatible in the 8.1 series, but not in the 8.0 series.

Anyway, I pushed d5b59fa5e6552da2baea9e9b6651b32e4bcde6dc to swipl-devel.git which fixes the issues. Turned out to be that MinGW32 provides POSIX clock_gettime() in its runtime library, but the function is broken on 32-bits.

Should be in tomorrows daily build.

3 Likes