Suggestion for @DATE[] input

[dcantor]

With the introduction of the new ISO-format dates formats 5 and 6, @DATE[], @DATECONV[], @MAKEAGE[], and other functions will accept a date specified with only two parts as if it were format 6.

ISO dates properly have 4-digit years, but TCC functions accept both 2- and 1-digit years.

The problem is, as I see it, that when a user manually enters a date with only two components, they are much more likely to mean month/date within the current year or date.month within the current year than some date in January in a low-numbered 21st century year. It is likely that a user who enters 04/07 means either April 7 or July 4 this year, and not Jan 7, 2004. Dates read from files, however, are likely to have the full 4-digit year and 3-digit day within the year.

So .BTM files processing file input would have no problem, but .BTM files handling user manual input may get incorrect dates.

I suggest that for recognition of a format 6 date where the input format is not explicitly stated, the year be required to be 4 digits. A 2-element date without a 'W' like 04-07 could be rejected as invalid format or interpreted as either day-month or month-day according to the default format. In older versions of TCC, a 2-element date was always rejected.

By way of example, my suggested is that @DATE[4-7,6] would be accepted as 2004-007 (and @DATE[2004-007] would be accepted as format 6), but @DATE[4-7] (without the ,6) would be either rejected or accepted as 04-07-%_year and interpreted as the default format (for formats 1 and 2) and for format 3 systems, it would be interpreted as %_year-04-07. Of course, not only @DATE, but also @DOW and all the other functions that take a date as input.

(Dates with a 'W', properly should have 4-digit years, but the 'W' truly does
make the intent unambiguous.)

 

[Steve Fabian]

dcantor wrote:
| With the introduction of the new ISO-format dates formats 5 and 6,
| @DATE[], @DATECONV[], @MAKEAGE[], and other functions will accept
| a date specified with only two parts as if it were format 6.
...
|
| I suggest that for recognition of a format 6 date where the input
| format is not explicitly stated, the year be required to be 4
| digits. A 2-element date without a 'W' like 04-07 could be rejected
| as invalid format or interpreted as either day-month or month-day
| according to the default format. In older versions of TCC, a
| 2-element date was always rejected.
...
| (Dates with a 'W', properly should have 4-digit years, but the 'W'
| truly does make the intent unambiguous.)

That would really be a DWIM function! Actually, I would much rather see a
new function, loosely modelled on @GETFOLDER[]:
@GETDATE[order or format, default value]
which would allow the ORDER to be specified explicitly using any one to all
three of the letters YMD, (or any one or two of them, or one of the format
codes 0..6. Any date field the interactive user skipped using the Esc or Tab
key would use the respective fields from the default value. The function
would display a dialog explicilty specifying what is expected in each field
(using the current language of TCC) and the default values. This function
would never be ambiguous, nor would it require guessing, and would eliminate
the need for TCC users to write any code to parse dates. The function ought
to validate that the entry is a valid date, too.
Naturally, a companion function @GETTIME ought to exist as well, with
analogous semantics.
--
Steve

 

[dcantor]

dcantor wrote:
| With the introduction of the new ISO-format dates formats 5 and 6,
| @DATE[], @DATECONV[], @MAKEAGE[], and other functions will accept
| a date specified with only two parts as if it were format 6.
...
|
| I suggest that for recognition of a format 6 date where the input
| format is not explicitly stated, the year be required to be 4
| digits. A 2-element date without a 'W' like 04-07 could be rejected
| as invalid format or interpreted as either day-month or month-day
| according to the default format. In older versions of TCC, a
| 2-element date was always rejected.
...
| (Dates with a 'W', properly should have 4-digit years, but the 'W'
| truly does make the intent unambiguous.)

That would really be a DWIM function! Actually, I would much rather see a
new function, loosely modelled on @GETFOLDER[]:
@GETDATE[order or format, default value]
which would allow the ORDER to be specified explicitly using any one to all
three of the letters YMD, (or any one or two of them, or one of the format
codes 0..6. Any date field the interactive user skipped using the Esc or Tab
key would use the respective fields from the default value. The function
would display a dialog explicilty specifying what is expected in each field
(using the current language of TCC) and the default values. This function
would never be ambiguous, nor would it require guessing, and would eliminate
the need for TCC users to write any code to parse dates. The function ought
to validate that the entry is a valid date, too.
Naturally, a companion function @GETTIME ought to exist as well, with
analogous semantics.
--
Steve

I'm not trying to propose a DWIM function; what I'm saying is that when the user enters a 2-element date, it probably won't result in what the user wants. Because of that, it's likely to be a DSOTWIM (Does Something Other Than What I Mean).

It can be solved by requiring the 4-digit year for an ISO yyyy-ddd date. Trying to interpret it as something else is secondary; an invalid date error is an acceptable result.

Maybe all we need is an @ISDATE function to test whether a string is a valid date without throwing an error.

Echo %@ISDATE[4-7]
0
Echo %@ISDATE[2004-007]
1