tedj@hpcid.HP.COM (Ted Johnson) (09/22/87)
I'm having a very wierd problem with Lightspeed C's time() and ctime()
functions. They both print out the correct time, except that they're both
exactly 5 hours fast!!
#include <unix.h>
#include <stdio.h> /*I also included just about
every manager there is.*/
main()
{
unsigned long a;
unsigned long clock;
time(&a);
printf("%s", ctime(&a));
printf("%s", ctime(NULL));
}
This program printed out "Mon Sept 21 05:55:01 1987"
"Mon Sept 21 05:59:01 1987",
but my JClock said "0:59:01", so I know that the problem
isn't that my system clock is set wrong.
This wierd behavior occurs with v2.01 and v2.11 of LSC,
on a Mac SE HD20 running 4.1/5.5.
Any clues are greatly appreciated!
-Ted
UUCP: hplabs!hpcea!hpcid!tedj
singer@endor.harvard.edu (Andrew Singer) (09/23/87)
In article <3320019@hpcid.HP.COM> tedj@hpcid.HP.COM (Ted Johnson) writes: >I'm having a very wierd problem with Lightspeed C's time() and ctime() >functions. They both print out the correct time, except that they're both >exactly 5 hours fast!! > > ...source example here... > I reproduced this behavior, and asked some questions, and looked at the library sources, and it seems that the time() and ctime() functions return Greenwich Mean Time (GMT), *not* local time. The fault lies with the documentation for not reporting this little fact, and will be corrected. If you need local time (or the machine's clock time) you can do something with the OS Utilites and the International Utilities Package: #include <MacTypes.h> #include <stdio.h> #include <OSUtil.h> #include <IntUtilPkg.h> /* this may not be the right name? */ main() { Str255 theDate, theTime; long secs; GetDateTime(&secs); IUDateString(secs, longDate, &theDate); IUTimeString(secs, TRUE, &theTime); printf("%s\n", &theDate); printf("%s\n", &theTime); } I haven't actually tested this, and it's not an exact replacement of the unix time function, but it (or something like it) should work. --Rich **Note: The opinions herein are my own opinions and are not necessarily representative of the opinions of my employer (THINK Technologies, Inc.) Richard M. Siegel Customer Support Representative THINK Technologies, Inc.
olson@endor.harvard.edu (Eric Olson) (09/24/87)
In article <2864@husc6.UUCP> singer@endor.UUCP (Andrew Singer) writes: > > I reproduced this behavior, and asked some questions, and looked >at the library sources, and it seems that the time() and ctime() functions >return Greenwich Mean Time (GMT), *not* local time. The fault lies with the >documentation for not reporting this little fact, and will be corrected. How does the library know where the computer is, to calculate GMT from the local time? -Eric Eric K. Olson olson@endor.harvard.edu harvard!endor!olson
singer@endor.UUCP (09/24/87)
In article <2867@husc6.UUCP> olson@endor.UUCP (Eric Olson) writes: > >How does the library know where the computer is, to calculate GMT from >the local time? Actually, that's another problem, which may well be classified as a bug. GMT is calculated based on Eastern Standard Time, and the fault is that the library assumes that local time *is* EST. (or EDT, as the case may be). I will probably fix this library; the problem is how to fix it; it's possible to just have time() and ctime() return the system clock time and date regardless, but if people have come to depend on the current functionality, it might be a problem. Any suggestions? --Rich **The opinions stated herein are my own opinions and do not necessarily represent the policies or opinions of my employer (THINK Technologies, Inc). Richard M. Siegel Customer Support Representative THINK Technologies, Inc.
tedj@hpcid.UUCP (09/24/87)
Oops, what I meant to say was that the above code output: Mon Sept 21 05:59:01 1987 Mon Sept 21 05:59:01 1987 when my JClock said: 0:59:01 -Ted
cheeser@dasys1.UUCP (Les Kay) (09/26/87)
Now that most machines have clocks, doesn't it make sence TO USE THEM? -- =============================================================================== Jonathan Bing, Master (cheeser) ...ihnp4!hoptoad!dasys1!cheeser Time flys like an Arrow, Fruit Flies like Bananas! ===============================================================================
whp@apr.UUCP (Wayne Pollock) (09/27/87)
Whenever a product changes functionality, you have this problem. For software,
a reasonable approach is to add a menu choice (which is remembered until reset)
called something like "version 2.01 compatibility mode". Add plenty of clear
documentation about the differences, and encourage everyone to not use the
feature, as it will be dropped in future releases. And several updates later,
you can drop the feature.
This is reasonable because software usually has a live span measured in a small
number of years; allowing people to compile old software for a while is ok, and
sooner or later it will be rewritten (you should provide help for this, perhaps
supplying new routines that work the way the old ones did), or it will be dis-
carded.
By the way, just what is the current release of LSC? The latest version I have
is 2.01, do I need to upgrade?
Wayne Pollock, ...!{inhp4, cbatt}!cbosgd!osu-cis!apr!whpjayn@oakhill.UUCP (Jay Norwood) (10/15/87)
Is there any good reason why LSC doesn't accept static function declarations at the start of a module? For example: static my_func(); The LSC compiler generates an error message for this. Jay Norwood
singer@endor.harvard.edu (Richard Siegel) (10/16/87)
In article <1018@oakhill.UUCP> jayn@oakhill.UUCP (Jay Norwood) writes: >Is there any good reason why LSC doesn't accept static function >declarations at the start of a module? >For example: >static my_func(); This is a prototype, and you can't declare prototypes as "static". We've heard a lot about this, but I don't know Mike's plans for it. If you want to prototype a static function, try this: long myfunc(int arg1, char *arg2); /* the prototype */ static long myfunc(arg1, arg2) /* the static function itself */ int arg1; char *arg2; --Rich **The opinions stated herein are my own opinions and do not necessarily represent the policies or opinions of my employer (THINK Technologies, Inc). * Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer * * Customer Support | singer@endor.harvard.edu * * THINK Technologies, Inc. (No snappy quote) *