View Source

[ |../../index.htm#lansa/l4wtgu02_0130.htm]
You are here:

Mandatory. Default=SYSFMT.
Rules
Allowable values are:

SYSFMT	operating system date format (from QDATFMT)
DDMMYY	day month year format
MMDDYY	month day year format
YYMMDD	year month day format
DDMMYYYY	day month century year format
MMDDYYYY	month day century year format
YYYYMMDD	century year month day format
YYYYDDMM	century year day month format
YYMM	year month format
MMYY	month year format
YYYYMM	century year month format
MMYYYY	month century year format
SYSFMT8	operating system date format including century

|
Date Format Examples
For example, the date 28th October 1986 would have to be entered as follows to satisfy each format type:

SYSFMT	281086 (Usual format for Australia and Europe)
SYSFMT	102886 (Usual format for USA)
DDMMYY	281086
MMDDYY	102886
YYMMDD	861028
DDMMYYYY	28101986
MMDDYYYY	10281986
YYYYMMDD	19861028
YYYYDDMM	19862810
YYMM	8610
MMYY	1086
YYYYMM	198610
MMYYYY	101986
SYSFMT8	28101986 (Usual format for Australia and Europe)
SYSFMT8	10281986 (Usual format for USA)

|
Tips & Techniques

In a client/server application, the client's date format will be automatically passed to the server. If the client and server date formats are different (e.g. MDY vs DMY), the server will automatically return data in the client's format.
The client's format can be changed from the default by specifying the X_RUN parameter DATF=. For more information, please refer to Standard X_RUN Parameters.
If client and server date formats are different (such as between USA and UK clients), date format validation rules specifying exact formats will fail. For example, DDMMYY may be returned as MMDDYY. Where clients need to use different date formats, date format SYSFMT is recommended.

[ |../../index.htm#lansa/l4wtgu02_0130.htm]