time() gcc and SAS/C differs

[Gilloo]

Hello,
can somebody explain why there is a little difference between time() in gcc and time() in SAS/C 6.58

gcc 1643366721
sas 1643388357

21636 ~ 6 hours

a kind of lag between us time and greenwitch ?
How to make this UTC ? (thanks !)

[paraj]

The value returned by time() is implementation defined. It's very common for it to be seconds since the unix epoch, but it's not guaranteed, and even then in some implementations it's adjusted to/from localtime (likely what you're seeing here). You can get the time expressed in UTC with gmtime, but that's in the broken-down (struct tm) format (Note that gmtime and localtime seem to return the same thing with VBCC and StormCPP though... EDIT: and gcc2.95 seems to assume the time is set to GMT and applies the offset wrong, what a mess).

[Gilloo]

sas seems to be CST Central Standard Time (UTC-6)
gcc GMT Greenwich Mean Time (UTC+0)

I found a workaround:
by creating an environment variable ENV:TZ containing GMT, time() under sas and gcc says the same thing.

[coldacid]

Not really a workaround, more what works to set the time zone used for local time by both GCC's C standard library and SAS/C's C standard library. Other standard library implementations may use the same or different environment variable, or have some completely different way of setting it. Also note that the epoch for time() can be different, although most (and as far as I know, all on Amiga, Linux, and Windows) use Jan 1, 1970. The actual underlying type of time_t is another implementation factor, keep in mind that you should never write your code assuming that time() returns an int or a long, and that if you want a particular calendar time and date from what you get from time() you need to use gmtime() or localtime().

[phx]

Originally Posted by paraj

Note that gmtime and localtime seem to return the same thing with VBCC

As documented in chapter 12.3.1 of vbcc.pdf:

long __gmtoffset

defines the offset in minutes, west of Greenwich.
(Maybe it should use TZ as well.)

[paraj]

Originally Posted by phx

As documented in chapter 12.3.1 of vbcc.pdf:

long __gmtoffset

defines the offset in minutes, west of Greenwich.
(Maybe it should use TZ as well.)

Not suggesting you should make any changes, but shouldn't it use something like OpenLocale(NULL)->loc_GMTOffset (if available) instead?


Then again I don't have much experience with systemfriendly amiga coding, so take it for what it's worth, I just looked at the standard and checked the compilers I had readily available on my system

[phx]

Originally Posted by paraj

Not suggesting you should make any changes, but shouldn't it use something like OpenLocale(NULL)->loc_GMTOffset (if available) instead?

Our vclib is designed to be portable, that's why it uses the offset-symbol by default. But you are right. That doesn't mean I couldn't initialize it properly on startup when running under AmigaOS.
Looking into it for the upcoming release...

EDIT: What format does this TZ environment variable have under AmigaOS? Is it POSIX compatible, like for example: "CET-1CEST..." ?

[coldacid]

If it works for GCC's standard C library, it's probably POSIX compatible. Just don't quote me on that.

[paraj]

Yeah, I think it's the format described here: https://pubs.opengroup.org/onlinepub...bd/envvar.html

Parsing seems to be handled in libixemul here: https://sourceforge.net/p/amiga/code...ic/localtime.c

I don't know to what extend the format is standardized in Amiga context nor how many programs will use it (Bebbo's libnix doesn't seem to use it for example).

[bebbo]

Originally Posted by paraj

...
(Bebbo's libnix doesn't seem to use it for example).

libnix supports the locale, which is not used per default, since that adds 2k size...



use `setlocale(LC_ALL, "");` or reference that function at least:

#include <locale.h>
void * __x = setlocale;

and the Amiga locale gets used.

[paraj]

Originally Posted by bebbo

libnix supports the locale, which is not used per default, since that adds 2k size...

use `setlocale(LC_ALL, "");` or reference that function at least:

#include <locale.h>
void * __x = setlocale;

and the Amiga locale gets used.

Yeah, but it doesn't parse the TZ POSIX "environment variable" (actually ENV: file for libixemul if I'm reading the source correctly), right?

Note that I think (without having any skin in the game) that it sounds totally reasonable. Seems like ideally you'd want: No gmtime/localtime/etc. functions -> No overhead, gmtime/localtime -> Use amiga locale, POSIX compliance -> default to amiga locale, optionally use TZ environment if present (though the value added seems quite dubious on most 3.x systems at least).

[bebbo]

Originally Posted by paraj

...
No gmtime/localtime/etc. functions -> No overhead,

gmtime/localtime -> Use amiga locale,

that can be done.

Originally Posted by paraj

...
POSIX compliance -> default to amiga locale, optionally use TZ environment if present (though the value added seems quite dubious on most 3.x systems at least).

hm...

[Gilloo]

I found this tricky workaround, but working
time_t t ;
long tz = 0 ; /* timezone shift, workaround for SAS/C time() */

#if defined(__SASC)
tz = timezone ;
#endif

time(&t) ;
t -= tz ;

// t get the same value for both sas/c or gcc

[phx]

My solution for the next vbcc release (just two more weeks) is to put a constructor into the vclib object file which defines __gmtoffset, to initialize it with GMTOffset from locale.library, when available - as suggested by paraj. So any code referencing __gmtoffset will enable the constructor.

I decided against any TZ environment parsing here, because it is too complex. And an Amiga without locale.library (like Kickstart 1.3) most likely has no TZ environment either.