BL> Borland says the opposite about their stat struct, but
BL> strftime() won't work in Unix anyway. I've had to write my own.
BL> What I am trying

PE> strftime() is ISO, and works under Unix.

BL> But strftime() won't work with time_t, you dickhead. It needs to be
BL> broken down into the tm struct... 

Yes, using localtime() or gmtime().  I suggest localtime().

BL> which is the problem anyway. I love
BL> the way it works... just move the problem along one.

Trust me, time works in C.  Which is more than you can say for Pascal.

BL> Now all I need is a function to turn the time_t long into a tm struct
BL> which is what I worte for myself. I can use mktime() to do the opposite,
BL> create the time_t struct from tm, but the book says that one won't work 
BL> in UNIX either... or do I just ignore that? How much of the book can I 
BL> ignore? Is there a standard for that too?

1. You ignore the Borland manual, and use ANSI_C.* from 3:711/934.

2. You ignore the Borland manual and use ISO/IEC 9945-1.  If that is not
available, then you need to guess, using the Borland manual as a hint.

BL> So far, the book says stat() works for DOS/UNIX but is not ansi, 

Yes.

BL> ctime() 
BL> in ansi 

Yes.

BL> and works for UNIX too, but strftime() and mktime() are ansi but 
BL> don't work for UNIX. 

ANYTHING that is ANSI works for Unix too.  What they probably mean is
whether it's a traditional Unix function (ala stat()), or whether it only
exists on Unix these days because the ANSI C standard introduced it.

BL> As usual, K&R handles the easy part (size) but dances right around
BL> time. I love this C language! 

Essentially, all systems have files, and all files have sizes.  Not all
systems have dates on the files.  The C64 doesn't even have a SYSTEM date. 
It only has a system TIME!

BL> timezone = 0;
BL> daylight = 0;

PE> Try setting the TZONE environment variable.

BL> I'm not worried about *me*, I'm worried about everyone else. It

So you document that you need to set that variable.

BL> seems that DOS comes preset to New York daylight saving. I don't want 
BL> to write a program that only works if people know how to run it. I
BL> want something bears can use... but it means I have to be smarter
BL> than the average bear.

Anyhow, that variable should only be relevant if you're using gtime()
instead of localtime().  If not, tell me what the results of gmtime() are
then.

BL> and then ctime() won't work!

PE> Says who?

BL> I just said it. If I set the times to zero, ctime() (local time)
BL> also has to be set to GMT or you get the wrong file date.

Oh, the files themselves are gmt are they?  Yeah well, you have to set up
the TZ variable then.

PE> Anyway, to fix the New York thing, see if it uses the TZ
PE> environment variable, ie try "set TZ=EST-10",

BL> ROFL!!! You have a weird idea of how to solve problems... just move
BL> it along one.

You have to set something in your config.sys to change the output of
"date" to use the Australian date format too.

 PE> you can use localtime() instead of gmtime()? 

BL> ctime *IS* localtime.

There is a separate function, localtime(), a lot more flexible.

BL> I love C. It's such a great language... and so portable, too.

PE> It is. What are you comparing it to, BTW? Something which won't
PE> even *compile* under Unix? 

BL> I am comparing it to what *you* said it was: a portable language
BL> using standardised functions. Pity about the reality...

Does your program compile on Unix?  (Yes).  Would your Turbo Pascal one have? (No).

BL> BTW, I was wrong about stat(). It works on a closed file and is
BL> very useful. Pity it's not ansi, though...

ANSI gives you something for all machines.  Posix gives you something for a
limited subset of all machines.  The really shitty thing about Posix is
that they put in fork(), making it virtually impossible to implement on
anything besides Unix.  So you normally don't find that implemented.  BFN. 
Paul.
@EOT:

---