MC: Date & Time

[Pat & Monica Yagle]

John H Meyers wrote:
>
> Here's a slightly different, but simple, HP48 User-RPL challenge:
>
> If we want to obtain both the current date and the current time,
> the obvious straightforward commands to use are DATE and TIME;
> however, because of the fact that these are separate commands,
> it is possible that the stroke of midnight occurs just after
> the execution of one of these commands and before the other,
> which would cause the pair of returned answers to be about
> 24 hours off from the true current date and time, e.g.:
>
> Current date is Aug 25, time is 23:59:59...
>
> DATE returns Aug 25
> [midnight strikes]
> TIME returns 00:00:00...
> [But it is now Aug 26 at 00:00, not Aug 25 at 00:00]
>

I came up with one that works. To get date and time from a single
"measurement" I used TICKS, then converted to days and time.

It's big and ugly, but it does work:

\<<
TICKS B\->R 707788800 / DUP IP SWAP FP
24 * \->HMS SWAP 726833 - 1.011990 SWAP DATE+
\>>

84.5 Bytes, Checksum # 834Fh

I guess I should mention that it works regardless of the current
date format.
--
Pat & Monica Yagle
mailto:ya...@flash.net

[John H Meyers]

Here's a slightly different, but simple, HP48 User-RPL challenge:

If we want to obtain both the current date and the current time,
the obvious straightforward commands to use are DATE and TIME;
however, because of the fact that these are separate commands,
it is possible that the stroke of midnight occurs just after
the execution of one of these commands and before the other,
which would cause the pair of returned answers to be about
24 hours off from the true current date and time, e.g.:

Current date is Aug 25, time is 23:59:59...

DATE returns Aug 25
[midnight strikes]
TIME returns 00:00:00...
[But it is now Aug 26 at 00:00, not Aug 25 at 00:00]

The problem is to write User-RPL instructions which can not possibly
fail to return a consistent pair of values for the current date and time;
naturally, a simple solution would be preferable.

This problem can occur with any operating system (e.g. MS-DOS) which
has independent commands for separately retrieving the date and time;
the problem even occurs in hardware when reading out clock values,
e.g. to make sure that the clock register is not incrementing
(generating "carries") while it is being read out.

Similar considerations arise in many on-line transaction processing
or other database systems where non-simultaneous updates may
temporarily leave inconsistent data in related records.

-----------------------------------------------------------
With best wishes from: John H Meyers <jhme...@mum.edu>

[joe...@mail.liberty.com]

In article <5ttfvp$g20$1...@news.iastate.edu>, jhme...@miu.edu wrote:
>
> The problem is to write User-RPL instructions which can not possibly
> fail to return a consistent pair of values for the current date and time;
> naturally, a simple solution would be preferable.

Here's one way of going about it:

<< WHILE TIME DATE TIME ROT OVER > REPEAT DROP2 END >>
BYTES: #781Bh 35.0

It works because the DATE command is straddled by two TIME's. Ordinarily
two TIME's are in numerical order; the second one is greater than the
first one. But if midnight strikes between them, then they will be out
of order. The program above handles that situation by dumping the invalid
time and date, and repeating.

-Joe-
joe...@usa.net

-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet

[Christian Meland]

John H Meyers <jhme...@miu.edu> wrote in article
<5ttfvp$g20$1...@news.iastate.edu>...

> Here's a slightly different, but simple, HP48 User-RPL challenge:
>
> If we want to obtain both the current date and the current time,
> the obvious straightforward commands to use are DATE and TIME;
> however, because of the fact that these are separate commands,
> it is possible that the stroke of midnight occurs just after
> the execution of one of these commands and before the other,
> which would cause the pair of returned answers to be about
> 24 hours off from the true current date and time, e.g.:
>
> Current date is Aug 25, time is 23:59:59...
>
> DATE returns Aug 25
> [midnight strikes]
> TIME returns 00:00:00...
> [But it is now Aug 26 at 00:00, not Aug 25 at 00:00]
>

> The problem is to write User-RPL instructions which can not possibly
> fail to return a consistent pair of values for the current date and time;
> naturally, a simple solution would be preferable.
>

> This problem can occur with any operating system (e.g. MS-DOS) which
> has independent commands for separately retrieving the date and time;
> the problem even occurs in hardware when reading out clock values,
> e.g. to make sure that the clock register is not incrementing
> (generating "carries") while it is being read out.
>
> Similar considerations arise in many on-line transaction processing
> or other database systems where non-simultaneous updates may
> temporarily leave inconsistent data in related records.
>

Hi.
First of all: Funny problem.
Here are my solution:

<< TIME DATE OVER TIME > NEG DATE+ >>
Bytes: #74Dh 27,5

Christian

--
Christian Meland
Research Scientist, PFI
Oslo, Norway
Phone +47 22566105 ext. 267, at home +47 22221067

[Jarno Peschier]

"Christian Meland" <christia...@pfi.no> wrote the following:

>> The problem is to write User-RPL instructions which can not possibly
>> fail to return a consistent pair of values for the current date and time;
>> naturally, a simple solution would be preferable.
>

>On befalf of my wife (and with a knife against my neck) I post the
>following:
>
>a) Why would anyone use that stupid thing around midnight?
>
>b) Program to use for those that use it anyway:
>
><< CLLCD
>IF
> "Is it very dark outside,
> or are you near one of
> the poles and feel that
> it's around midnight?
> (Y/N)"
> 1 DISP
> 0 WAIT
> 52.1 ==
>THEN
> "Goto bed,
> get some sleep, a life
> (and a wife)!"
> 1 DISP
> 7 FREEZE
>ELSE
> DATE TIME
>END
>>>
>
>Bytes #AOUCh unknown
>
>Christian's wife.

Funny, very funny. But we are *dead serius* here. Your wife obviously
is not a HP48 pillow hacker...

And the above program does not qualify for at least two reasons:
1) It cannot possibly be the shortest one found.
2) It needs user intervention to work.

<grin>

Jarno Peschier, computer science student, Utrecht University
mailto:jpes...@cs.ruu.nl http://jarno.home.ml.org/
____________________________________________________________
'avwI' nejDI' narghta'bogh qama' reH 'avwI' Sambej

[John H Meyers]

The challenge was to simply get the current DATE and TIME;
however, there is just one potential problem:

Usually the separate commands DATE and TIME return values
which "belong together," but if we are running a program
just as midnight occurs, and if midnight actually strikes
between these two separate commands, one of the commands
returns a value which was correct for the end of the previous day,
while the other returns a value which is correct for the
beginning of the next day, and the pair of values taken together
represents a moment about 24 hours away from a correct combination.

Several people took the route of examining and interpreting the
TIME value in order to resolve this, but there is another way
which works no matter what operating system is used, and no
matter what the format of the date and time; it will even work
if several hours (or even days) elapse between commands
(except of course that the valid Date and Time pair will
be as of when the TIME command was actually last performed):

Perform DATE, then TIME, then DATE again; if the date has not
changed, then midnight did not strike, and the date and time
values are guaranteed to be consistent. If the date did change,
there is no need to analyze the time value to guess to which
date it belongs; rather, just throw out all the values and start
over again; the next time, the values will be consistent,
and you will obtain a guaranteed valid pair of values.

One way to do this on the HP48 is:

\<< WHILE DATE TIME OVER DATE \=/ REPEAT DROP2 END \>>

(where \=/ represents the "unequal" symbol on the HP48)

This is very close to Joe Horn's suggestion, except that
we do not need to presume anything about the time format,
nor about how little time elapses between commands.