I thought it was possible to convert a date stored as string in the format "YYYYMMDD" to SDATE directly using just SDATE8 format but apparently not?
=====================
To manage your subscription to SPSSX-L, send a message to
[hidden email] (not to SPSSX-L), with no body text except the
command. To leave the list, send the command
SIGNOFF SPSSX-L
For a list of commands to manage subscriptions, send the command
INFO REFCARD
/* Works OK: */. DATA LIST /ID 1-1 (F) DATESTR 2-11 (SDATE) . BEGIN DATA. 12015 05 31. END DATA. /* ERORR :*/. DATA LIST /ID 1-1 (F) DATESTR 2-9 (SDATE) . BEGIN DATA. 120150531. END DATA. >Warning # 1152 >A field to be read under the SDATE format is invalid. The field must contain >year, month, and day separated by spaces, dashes, slashes, decimal points, or >commas. The result has been set to the system-missing value. >Command line: 1656 Current case: 1 Current splitfile group: 1 >Field contents: '20150531' >Record number: 1 Starting column: 2 Record length: 1024 Thanks in advance, Jignesh |
As the error message says, The field must contain >year, month, and day separated by spaces, dashes, slashes, decimal points, or >commas On Mon, Aug 8, 2016 at 7:14 AM, Jignesh Sutar <[hidden email]> wrote:
|
But why? Why isn't an input format YYYYMMDD good enough for conversion? Why an unecessary step for string manipulation to get into desired format to then apply conversion?
=====================
To manage your subscription to SPSSX-L, send a message to
[hidden email] (not to SPSSX-L), with no body text except the
command. To leave the list, send the command
SIGNOFF SPSSX-L
For a list of commands to manage subscriptions, send the command
INFO REFCARD
On Mon, 8 Aug 2016 at 14:39 Jon Peck <[hidden email]> wrote:
|
This rule applies to all the date formats except JDATE. It has been that way for hundreds of years. I don't know why it was done that way, but I suspect it was done to minimize the likelikhood of errors when ambiguous entries that might arise with single-digit month or day numbers entered incorrectly. But in version 24 (at my suggestion), which also added ISO8601 format, from the CSR, "For version 24 and higher, delimiters can be omitted in input values for DATE, ADATE, EDATE, and SDATE. For example, with the ADATE format, the form 10281990 is acceptable. When delimiters are omitted, single digit specifications for month and day are not supported and year specifications must be 2 or 4 digits. Also, when month names are used, they must be specified in the three letter format when delimiters are omitted, as in 28OCT1990." On Mon, Aug 8, 2016 at 8:24 AM, Jignesh Sutar <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |