1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Suggestion for @DATE[] input

Discussion in 'Support' started by dcantor, Oct 13, 2009.

  1. dcantor

    Joined:
    May 29, 2008
    Messages:
    507
    Likes Received:
    3
    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.)
     
  2. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    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
     
  3. dcantor

    Joined:
    May 29, 2008
    Messages:
    507
    Likes Received:
    3

    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
     

Share This Page