[[https://www.revelation.com/|Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community]]
==== DATE() and TIME() synchronization (AREV Specific) ====
=== At 06 MAY 2003 06:14:13PM Victor Engel wrote: ===
{{tag>"AREV Specific"}}
I've found that in our current processing there is a small but significant number of instances when date() and time() calls on consecutive lines in a program execute on different calendar days if processing occurs at midnight. Normally, I don't code for this, but our current situation apparently requires it.
If you think about it, there is always a finite amount of time that elapses between consecutive lines of code execution. So if you have, for example:
X=DATE()
Y=TIME()
the first line executes some finite amount of time prior to the second line. If this time difference spans midnight, timestamp calculations could be off by a day. Suppose, for example, you log the date and time of transactions. If the TIME() call occurred after midnight and the DATE() call occurred prior to midnight, the timestamp will appear to have occurred about a day earlier than it actually did.
One possible solution is to do something like this:
LOOP
DT1=DATE()
TM=TIME()
DT2=DATE()
UNTIL DT1=DT2
REPEAT
This loop will execute once unless processing occurs right at midnight, in which case it executes twice and corrects itself.
There is an RBasic function called TIMEDATE() that returns a string of the date and time together. I assume this uses its own single call to get the date and time vs. making separate calls for date and time and then concatenating. If someone knows otherwise, please correct me.
So, I'm wondering if any of you use the above logic or if you have an alternate scheme that you use.
----
=== At 07 MAY 2003 06:02AM Joe Doscher wrote: ===
Good morning Victor,
Try the RBASIC TIMEDATE()function. It returns a string value expressing the current time and adte in external format.
Hope this helps you.
Joe Doscher
Rev. Tech. Support.
----
=== At 07 MAY 2003 07:50AM Don Miller - C3 Inc. wrote: ===
Victor..
This error has been around since the year dot .. the synchronization of date/time right around midnight. I have used the looping function since REV-F. The TIMEDATE function is still prone to the same kind of error (I think) since it encapsulates both calls. There's another time wierdness, too. The system doesn't know the difference between 86400 (midnight of one day) and 0, the start of the next day. We've had to deal with this in our scheduling software for a long time too. In a situation where an event starts at say 11:00 pm on one day and ends at 7:00 the next day, computing elapsed time (ELAP_TIME) in the normal way will yleld a negative number (ELAP_TIME=E_TIME-S_TIME) unless you modify it to read ELAP_TIME=E_TIME-S_TIME+(86400*(E_TIME < S_TIME)).
Don M.
----
=== At 07 MAY 2003 10:27AM Victor Engel wrote: ===
Yes, I mentioned that function in my original post. But then I'd have to parse it and iconv each part. That would seem to be more expensive than doing date() twice.
----
=== At 07 MAY 2003 12:43PM Don Miller - C3 Inc. wrote: ===
Victor ..
I agree wholeheartedly. It doesn't help much even if you get the whole mess in internal format either since you'll have to parse that too. A double call is very quick, IMO.
Don M.
----
=== At 07 MAY 2003 08:52PM Curt Putnam wrote: ===
Don't have that particular problem, but have found that one cannot use a time() call as part of a key. It's fast enough that duplicates are possible
----
=== At 08 MAY 2003 10:18PM Steve Smith wrote: ===
SECONDS.SINCE.MIDNIGHT.01.01.1968=(DATE() * 86400) + TIME()
is one technique I've seen used.
Another possibility is the Eric Emu [url=http://www.sprezzatura.com/senl/volume_2_issue_6.htm#_Toc445126844]finetime()[/url] routine from SENL to return the number of ticks since midnight. This gives finer gradations than seconds (1/1000 second). FINETIME() also delays by 1000th of a second with no parameter, so using locks on non-existent LISTS keys for a microsecond would be possible.
If I recall REVG and early AREV 1.x used to return yesterday's date from DATE() under some DOS versions in the time just after midnight.
Steve
----
=== At 12 MAY 2003 11:15AM Hippo wrote: ===
I never should have solve this problem before.
Some thoughts:
a) Steve's call f(DATE()+TIME()) does not solve the problem.
b)
LOOP
DT=DATE()
TM=TIME()
DT2=DATE()
UNTIL DT=DT2
REPEAT
speedup:
DT=DATE()
LOOP
TM=TIME()
DT2=DATE()
UNTIL DT=DT2
TRANSFER DT2 TO DT
REPEAT
but you probably never mind which day it will be, but it must be compatible with time ...
DT=DATE()
TM=TIME()
DT2=DATE()
if TM
----
=== At 12 MAY 2003 05:05PM Victor Engel wrote: ===
"If I recall REVG and early AREV 1.x used to return yesterday's date from DATE() under some DOS versions in the time just after midnight."
I think this is exactly what I'm running into.
----
=== At 12 MAY 2003 09:15PM Warren wrote: ===
That's a bug in some versions of DOS and PC BIOS actually. The so-called "midnight bug" See
[url=http://www.geocities.com/geoff_wass/dBASE/GaryWhite/dBASE/FAQ/qmidn.htm]here[/url]for info.
Then there's the Midnight Rollover "bug" which is probably what you are running into: "this bug can strike code once per day. The "Midnight Rollover" bug occurs in any system which obtains date and time independently, without checking that the date has remained unchanged around the reading of the time. If the date and time are read just before midnight, there is a small but finite risk that the time will have rolled over from 23:59:59 to 00:00:00 the next day between the two readings."
----
=== At 12 MAY 2003 09:23PM Warren wrote: ===
This may be [url=http://www.codeproject.com/datetime/dstbugs.asp] useful[/url] too.
[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=1828F603A483CD7A85256D1E007A26C3|View this thread on the forum...]]