> What is the secret to interpreting QSO timestamps correctly? I know
> they are stored as C time_t values (number of seconds since 1/1/1970).
> When I convert them back to date/time values, I end up being 7 or 8
> hours off (it varies with the contest). Does the CQ zone one enters on
> the first screen have anything to do with the stored timestamp? I
> almost always have my computer clock set to UTC. Depending on the C
> compiler and environment variables like "TZ", C functions like gmtime
> and localtime can do funny things to a time_t value. Some assume the
> system clock is always set to Eastern Time unless you say otherwise by
> adjusting the TZ (timezone) environment variable.
CT 7 was based on the Borland C++ compiler and uses calls to time(long *)
to get times. The returned number is the same as the one Microsoft compilers
produce. I *think* this is 7 hours off from GMT. CT7 allowed you to
leave your computer on localtime and use an evironment variable to
indicate the offset. I abandoned that in version 8 because so many
guys screwed themselves up in CQWW SSB with the time change on Saturdy
night.
CT8 is based on the Zortech C++ compiler. I *think* it returns numbers
14 hours off of Microcosft and 7 hours the other way .
Each compiler is consistant and the localtime() function produces the
correct time when combined with time().
CT uses localtime, but not gmttime...Zortech doesn't support it.
>
> Does CT8 use gmtime and localtime internally? Does it care about the
> CQ zone or the time zone or the environment variables? Did CT7 use
> gmtime and localtime?
>
> What's the best way to interpret timestamps correctly, for both CT 8
> and CT 7 bin files?
>
> Bob, N6TV
I suggest you measure the output of each program, and use any offset you
need to match your compiler.
--
Ken Wolff K1EA
|