Date Math

[Fairlight]

Confusious (Kenneth Brody) say:
> 
> But, given that filePro already has date math and time math, all you
> need to do is subtract the two dates, multiply by 24 (to get hours),
> and add the difference of the times.

I don't see how this:

>     deltatime = (date2-date1)*"24" + (time2-time1)

accounts for an earlier time2 than time1.  7 - 11 == -4.  I don't think you
want to -subtract- four hours.

That's why I did it my way, way back.

What obvious and simple fact am I overlooking?  I ask this because I know
you well enough to know you'd never post a solution without -knowing- it
works.  So some assumption I'm making is incorrect.  But I'm not seeing it,
given that the raw time is entirely detached from the date data.  To me,
such a solution would come up 4hrs shorter than the actual amount from the
day calculation, plus you'd come up short on the actual extent, so it's a
cumulative loss.

That's how I'm seeing it.

Now, what's the part of the reality that I'm being blind to?  It's gotta be
dead simple, but I'm not getting it.

> While there might be use for such a function, there is no need for it
> here.

I've had use for such function many times.  I wish it had gone in with the
PID() and PPID() functions so we could finally easily make TRULY unique
identifiers for transactions.  That combination key is one of the best ways
to get unique identifier, and it's unavailable unless you use USER or
SYSTEM.

> How "rough" is:

Not.  Assuming it's actually correct.  As I said, I'm not seeing it, but
I'd like to.  

However, flat timestamps are far more easily manipulated, IMHO.  And yes, I
think like a C or perl programmer, not an fP programmer, granted.  I still
believe it's more generally useful a format, and it's also standard.  It's
a least common denomenator, and I really believe that at the -storage-
level, all data should be stored in its most generalised format, letting
you most easily convert upwards to any representational style you need at
the UI level.  Going from representational style A to representational
style R with any intermediate steps is simply more work than it's worth.
But that's just my take.  I'd -almost- bet Jay and a few others would
agree.  Fairly confident, but I admit I could be alone here.

> And would people on something other than "Unix" complain about
> such a function name?  :-)

None of the people using win32 perl seem to have a problem with time()
being equivalent to time(2).  True 'doze programmers...who knows, who
cares?  Fine, call it epochtime() if it's that big a concern.  :)

Not trying to turn anything into a religious war.  I would like the feature
for use when using future implementations that other people have deployed
where they want some things I can't easily get, sure.  But I'm out in 3rd
party land there.  Mostly it was just a simple comment that, lacking that
functionality, the other method is how I'd do it.

mark->