G'Day David,
 
-=> Quoting David Nugent to Frank Adam <=-

 FA> ** The world began in 1900...according to time.h
 DN> Not quite. The actual epoch date can be anything, according 
 DN> to the fancy of the vendor. You can't rely on a specific 
 DN> epoch date. Most compilers - certainly all under UNIX I've 
 DN> ever used - use 01-Jan-1970 as their epoch. It may differ 
 DN> on other platforms. Microsoft 7.0 uses 1900, but earlier 
 DN> and later versions of the same compiler use 1970. AFAIK, 
 DN> Borland and Watcom have always used 1970.
That sounds like the date all your XT user clients would put on their
cheques.:-)   
Which brings me to ask if it wasn't/isn't just a BIOS limitation ? 
ANSI says the year in the time struct is from 1900. So does turbo C.
                                                              
 FA>  long a =
 FA> (long)
 FA>  ((long)
 FA>   ((long)(367 * y1)-1.75 * y1 + d1->day)-0.75 * (0.01 * y1)) + 1721119L;

 DN> Won't you run into problems with rounding mixing float/doubles with
 DN> long? 
It worked ok. i've put in a y/m/d loop to do a few years and the output was
correct. 
I won't even pretend to claim that i know how it works, it was just a
plain conversion.In the actual VB code they've used ints in place of the 
longs, but that caused some problems in C. 
Perhaps the idea IS to lose the decimals. But come to think of it, i have
everything turned on, and had no warnings about loss of precision. 

 DN> I honestly don't know since never tried myself. I tend to 
 DN> stick with integer math wherever possible, and in this case 
 DN> you don't really need floating point anyway.
Agreed, Paul mentioned the one in SNIPPETS, i forgot about that one.       
                                        

  L8r Frank (fadam{at}ozemail.com.au).
  
___ Blue Wave/DOS v2.21

--- Gash