English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Language > Coders. C/C++

 
 
Thread Tools
Old 28 January 2022, 10:58   #1
Gilloo
Registered User
 
Join Date: Nov 2010
Location: Grenoble, Isère, Rhône-Alpes, France, Europe, Earth
Posts: 228
time() gcc and SAS/C differs

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 !)
Gilloo is offline  
Old 28 January 2022, 15:18   #2
paraj
Registered User

 
Join Date: Feb 2017
Location: Denmark
Posts: 255
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).

Last edited by paraj; 28 January 2022 at 15:26.
paraj is offline  
Old 28 January 2022, 15:52   #3
Gilloo
Registered User
 
Join Date: Nov 2010
Location: Grenoble, Isère, Rhône-Alpes, France, Europe, Earth
Posts: 228
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.
Gilloo is offline  
Old 28 January 2022, 19:18   #4
coldacid
WinUAE 4000/40, V4SA
coldacid's Avatar
 
Join Date: Apr 2020
Location: Candinavia
Posts: 474
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().
coldacid is offline  
Old 28 January 2022, 23:00   #5
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,151
Quote:
Originally Posted by paraj View Post
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.)
phx is offline  
Old 28 January 2022, 23:53   #6
paraj
Registered User

 
Join Date: Feb 2017
Location: Denmark
Posts: 255
Quote:
Originally Posted by phx View Post
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
paraj is offline  
Old 29 January 2022, 19:11   #7
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,151
Quote:
Originally Posted by paraj View Post
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..." ?

Last edited by phx; 29 January 2022 at 20:30. Reason: TZ
phx is offline  
Old 30 January 2022, 04:12   #8
coldacid
WinUAE 4000/40, V4SA
coldacid's Avatar
 
Join Date: Apr 2020
Location: Candinavia
Posts: 474
If it works for GCC's standard C library, it's probably POSIX compatible. Just don't quote me on that.
coldacid is offline  
Old 30 January 2022, 11:27   #9
paraj
Registered User

 
Join Date: Feb 2017
Location: Denmark
Posts: 255
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).
paraj is offline  
Old 30 January 2022, 19:32   #10
bebbo
botcher

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 601
Quote:
Originally Posted by paraj View Post
...
(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:

Code:
#include <locale.h>
void * __x = setlocale;
and the Amiga locale gets used.
bebbo is offline  
Old 30 January 2022, 19:49   #11
paraj
Registered User

 
Join Date: Feb 2017
Location: Denmark
Posts: 255
Quote:
Originally Posted by bebbo View Post
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:

Code:
#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).
paraj is offline  
Old 30 January 2022, 20:08   #12
bebbo
botcher

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 601
Quote:
Originally Posted by paraj View Post
...
No gmtime/localtime/etc. functions -> No overhead,

gmtime/localtime -> Use amiga locale,

that can be done.



Quote:
Originally Posted by paraj View Post
...
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...
bebbo is offline  
Old 31 January 2022, 21:58   #13
Gilloo
Registered User
 
Join Date: Nov 2010
Location: Grenoble, Isère, Rhône-Alpes, France, Europe, Earth
Posts: 228
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
Gilloo is offline  
Old 04 February 2022, 16:14   #14
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,151
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.
phx is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
CIA access speed differs with Amiga model patrik support.Hardware 14 29 December 2021 08:33
Sas/C vs. GCC regarding graphics.library Steffest Coders. C/C++ 7 27 October 2017 03:52
gcc sas/c link problem emufan Coders. C/C++ 6 23 July 2017 00:32
(Useless benchmark) Dhrystone on Sas C/Gcc/Vbcc alkis Coders. System 3 16 October 2013 13:03
pinballs - same game speed or calcs differs Chain Retrogaming General Discussion 4 01 March 2009 21:02

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 18:11.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.
Page generated in 0.08984 seconds with 15 queries