× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Putting current date/time into D/T/Z fields
  • From: Hans Boldt <boldt@xxxxxxxxxx>
  • Date: Wed, 8 Jul 1998 08:54:28 -0400

Paul wrote:
>With the enhancements to RPG IV in V3R7 and above I have a question >regarding
>which is now the best method to populate date/time/timestamp fields
>with the current date & time?
>
>Previously I have used a TIME operations to a data structure and then used
>MOVE with *JOBRUN in factor 1 to date & time fields.  I understand that you
>can now TIME directly to date & time fields.
>
>So my question is which of the following methods is now the preferred
>method for populating date/time fields:
>
>a)         TIME to a data structure, then *JOBRUN  MOVE to date field,
>*JOBRUN MOVE to time field
>
>b)   TIME   DateField
>      TIME   Timefield
>
>I look forward to your comments, especially from Jon and Hans at IBM.

There's a couple of other methods:

c) Initialize your date and time fields using INZ(*SYS).
The fields will be initialized at program initialization
to the system date/time.

d) Use opcode TIME with a timestamp field as the result
and MOVE that value to your date and time fields.  (This
is cleaner than using *JOBRUN on your MOVE.)

I don't have any strong opinions or preferences in the
matter.  The choice depends on how the dates and times
are used.  For example, if all dates and times must
indicate the exact same moment in time, you can't use
multiple TIME opcodes since the value returned may be
different each time.  (Certainly, timestamp will differ
by a couple of milliseconds.)  Option (d) would be
required in that case.

I do have one strong recommendation:  Within your
application, do ALL date processing in the default
*ISO format.  Use 2 digit years only on printed
reports, but then, only if your users and customers
insist on it.  So avoid format *JOBRUN since it applies
only to 2-digit years.  (If the reasons for this aren't
immediately obvious, just wait for 541 days and then
see how well your systems run!  :-)

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.