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

ISO 8601 support

Discussion in 'Support' started by K_Meinhard, Sep 7, 2008.

  1. K_Meinhard

    Joined:
    May 20, 2008
    Messages:
    310
    Likes Received:
    0
    Hi Rex,

    I'm playing around with the date vars and functions. I guess you'll have
    to take a closer look:

    As already written, it's about ISO 8601, _not_ 9601. Please correct the
    help text.

    Today is Sunday, 2008-09-07:

    Function @idowf:

    [C:\Programme\JPSoft\TCMD9]echo %@idowf[%_date,4]
    Samstag

    meaning Saturday.

    [C:\Programme\JPSoft\TCMD9]echo %@idowf[%_date,0]
    Sonntag

    [C:\Programme\JPSoft\TCMD9]echo %@idowf[%_date,2]
    Sonntag

    gets it right.

    Of corse @idow if off too:

    [C:\Programme\JPSoft\TCMD9]echo %@idow[%_date,2]
    So

    [C:\Programme\JPSoft\TCMD9]echo %@idow[%_date,4]
    Sa

    Function @dowf:

    [C:\Programme\JPSoft\TCMD9]echo %@dowf[%_date,4]
    Saturday

    is also off from Sunday.

    Function @dowi:

    [C:\Programme\JPSoft\TCMD9]echo %@dowi[%_date,0]
    1

    [C:\Programme\JPSoft\TCMD9]echo %@dowi[%_date,4]
    7

    4 gets it right. My guess is that 2 should deliver 7, as in most
    European countries Sunday is the last day of the week.

    Function @day:

    [C:\Programme\JPSoft\TCMD9]echo %@day[%_date,2]
    7

    [C:\Programme\JPSoft\TCMD9]echo %@day[%_date,4]
    8

    Now that is interesting. Today if still Sept. 07.

    Function @month:

    [C:\Programme\JPSoft\TCMD9]echo %@month[%_date,4]
    9

    Shouldn't this return a 2-digit minth with a leading zero?

    Function @year:

    [C:\Programme\JPSoft\TCMD9]echo %@year[%_date,2]
    08

    [C:\Programme\JPSoft\TCMD9]echo %@year[%_date,4]
    07

    Off by on year. ISO format should always be 4 digits.

    * Klaus Meinhard *
    4DOS Info - Info for DOS
    www.4dos.info
     
  2. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    K_Meinhard wrote:
    | Hi Rex,
    |
    | I'm playing around with the date vars and functions. I guess you'll
    | have
    | to take a closer look:
    |
    | As already written, it's about ISO 8601, _not_ 9601. Please correct
    | the help text.
    |
    | Today is Sunday, 2008-09-07:
    |
    | Function @idowf:
    |
    | [C:\Programme\JPSoft\TCMD9]echo %@idowf[%_date,4]
    | Samstag
    |
    | meaning Saturday.
    |
    | [C:\Programme\JPSoft\TCMD9]echo %@idowf[%_date,0]
    | Sonntag
    |
    | [C:\Programme\JPSoft\TCMD9]echo %@idowf[%_date,2]
    | Sonntag
    |
    | gets it right.
    |
    | Of corse @idow if off too:
    |
    | [C:\Programme\JPSoft\TCMD9]echo %@idow[%_date,2]
    | So
    |
    | [C:\Programme\JPSoft\TCMD9]echo %@idow[%_date,4]
    | Sa
    |
    | Function @dowf:
    |
    | [C:\Programme\JPSoft\TCMD9]echo %@dowf[%_date,4]
    | Saturday
    |
    | is also off from Sunday.
    |
    | Function @dowi:
    |
    | [C:\Programme\JPSoft\TCMD9]echo %@dowi[%_date,0]
    | 1
    |
    | [C:\Programme\JPSoft\TCMD9]echo %@dowi[%_date,4]
    | 7
    |
    | 4 gets it right. My guess is that 2 should deliver 7, as in most
    | European countries Sunday is the last day of the week.
    |
    | Function @day:
    |
    | [C:\Programme\JPSoft\TCMD9]echo %@day[%_date,2]
    | 7
    |
    | [C:\Programme\JPSoft\TCMD9]echo %@day[%_date,4]
    | 8
    |
    | Now that is interesting. Today if still Sept. 07.
    |
    | Function @month:
    |
    | [C:\Programme\JPSoft\TCMD9]echo %@month[%_date,4]
    | 9
    |
    | Shouldn't this return a 2-digit minth with a leading zero?
    |
    | Function @year:
    |
    | [C:\Programme\JPSoft\TCMD9]echo %@year[%_date,2]
    | 08
    |
    | [C:\Programme\JPSoft\TCMD9]echo %@year[%_date,4]
    | 07
    |
    | Off by on year. ISO format should always be 4 digits.

    Klaus, you misinterpreted how _date and the date format codes function.

    %_DATE is the current date, always in the format specified by the operating
    system, i.e., the "Regional Sttings" features of Microsoft Windows. In 4DOS
    this was based on the "country" code.

    In the various functions which accept a full date input and a date format
    code the format code tells the function how to parse the date.

    In your examples, you used the identical string, but asked the command
    processor to view it differently. Assuming you use German convention, %_date
    in all of your examples was 07/09/08, this is how you asked it to be
    interpreted:

    Format 0 should always be correct - which is why it is the default when no
    format is specified.
    Format 1: July 9, 2008
    Format 2: Sept. 7, 2008
    Format 3: Sept. 8, 2007
    Format 4: Sept. 8, 2007

    Format 4, the _isodate format and its related functions were created after
    several of us, myself included, requested that a country-independent format
    be available for portability.

    I am probably responsible for the incorrect ISO standard number in the
    documentation (when I worked on the help files), I based it on inadequate
    research (just postings in the JPsoft NG).
    --
    HTH, Steve
     
  3. K_Meinhard

    Joined:
    May 20, 2008
    Messages:
    310
    Likes Received:
    0
    Steve,



    Ah, now I see.


    I was among them. And I am still astonished that not even the European
    style / ISO style DOW (Mon=1, Tue=2,... Sun=7)) was implemented. This
    leads to programming contortions everytime we need date vars und
    functions.


    I'm not after responsibility, but after correction.

    And I'd like to renew my wish for a full set of ISO 8601 date and time
    functions in TCC.

    Mit freundlichem Gruß,

    Klaus Meinhard
     
  4. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    K_Meinhard wrote:
    | I was among them. And I am still astonished that not even the European
    | style / ISO style DOW (Mon=1, Tue=2,... Sun=7)) was implemented. This
    | leads to programming contortions everytime we need date vars und
    | functions.

    Blame it on Unix. The date structures supported by the MS APIs are those
    copied from Unix, which uses 0-based numbering (offset, not index) and US
    definition of "week". Standardized by IEEE as "Posix".

    | And I'd like to renew my wish for a full set of ISO 8601 date and time
    | functions in TCC.

    Post in the TC suggestion NG the list of functions and variables you want
    (preferrably with complete specifications and examples). You might see your
    wish come true!
    --
    Steve
     
  5. K_Meinhard

    Joined:
    May 20, 2008
    Messages:
    310
    Likes Received:
    0
    Steve FXbiXn wrote:
    ^

    I think that Lucho Georgiev has done a much more logical thing with 4DOS
    V. 777: the second parameter for @makedate, @makeage, @agedate etc.
    convert the linput to the desired output:


    C:\...\4DOS777>echo %@makedate[%@date[%_date],0]
    07.09.08

    C:\...\4DOS777>echo %@makedate[%@date[%_date],1]
    09.07.08

    C:\...\4DOS777>echo %@makedate[%@date[%_date],2]
    07.09.08

    C:\...\4DOS777>echo %@makedate[%@date[%_date],3]
    08.09.07

    C:\...\4DOS777>echo %@makedate[%@date[%_date],4]
    2008-09-07

    C:\...\4DOS777>echo %@makedate[%@date[%_date],5]
    2008-W36-7


    I have posted that wish already, and I'm sure Rex is aware of it. As
    Lucho has proved for 4DOS, a set of ISO compliant vars and functions is
    not an impossible feat. European users need ISODOWI, ISOWOY, and the
    output of date functions with second parameter 4 should be ISO
    compliant.

    Mit freundlichem Gruß,

    Klaus Meinhard
     
  6. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    K_Meinhard wrote:
    | Steve Fabian wrote:
    || Blame it on Unix. The date structures supported by the MS APIs are
    || those copied from Unix, which uses 0-based numbering (offset, not
    || index) and US definition of "week". Standardized by IEEE as "Posix".

    | I think that Lucho Georgiev has done a much more logical thing with
    | 4DOS
    | V. 777: the second parameter for @makedate, @makeage, @agedate etc.
    | convert the linput to the desired output:
    |
    |
    | C:\...\4DOS777>echo %@makedate[%@date[%_date],0]
    | 07.09.08
    |
    | C:\...\4DOS777>echo %@makedate[%@date[%_date],1]
    | 09.07.08
    |
    | C:\...\4DOS777>echo %@makedate[%@date[%_date],2]
    | 07.09.08
    |
    | C:\...\4DOS777>echo %@makedate[%@date[%_date],3]
    | 08.09.07
    |
    | C:\...\4DOS777>echo %@makedate[%@date[%_date],4]
    | 2008-09-07
    |
    | C:\...\4DOS777>echo %@makedate[%@date[%_date],5]
    | 2008-W36-7

    The output for formats 1..4 are the same in 4nt5 and later. No older 4nt
    here. Only format 5 is not available.

    || Post in the TC suggestion NG the list of functions and variables you
    || want (preferrably with complete specifications and examples). You
    || might see your wish come true!

    | I have posted that wish already, and I'm sure Rex is aware of it. As
    | Lucho has proved for 4DOS, a set of ISO compliant vars and functions
    | is
    | not an impossible feat. European users need ISODOWI, ISOWOY, and the
    | output of date functions with second parameter 4 should be ISO
    | compliant.

    Once again only @makedate and @agedate accept more than one parameter for
    controlling output format, and do exactly what you asked for, and have done
    so from at least 4nt v5 (for @agedate, since it was introduced). In all
    other date functions that accept 2 parameters the 2nd parameter specifies
    the parsing rule for the first parameter, the date, and all accept values
    from 0 to 4.

    There is only one function whose value is different from the ISO 8601 value,
    @DOW. IMHO it would be disastrous to change @DOW to return the ISO 8601
    value when parameter 2 is set to 4, as it would break all existing batch
    files which use it. A far better idea is to ADD a new function @ISODOW,
    which could be a simple user defined function (using the default definition
    of ParameterChar):

    function isodow=`%@if[%@dow[%$] EQ 0,7,%@dow[%$]]`

    UNTESTED!
    --
    Steve
     
  7. K_Meinhard

    Joined:
    May 20, 2008
    Messages:
    310
    Likes Received:
    0
    Steve FXbiXn wrote:

    VERY!!!

    I think you mean %@DOWI, which now shows 1=Sun, 2=Mon...3=Sat. It
    doesn't show 0 for any day.

    Nobody ever proposed to change that. All I (and probably others) would
    like to see is an @ISODOWI giving 1=Mon, 2=Tue, 7=Sun.

    I'd like to see the other vars and functions claiming to give ISO 8601
    output really do so, and I'd like to see an
    %@ISOWOY and %_ISOWOY. What Lucho did for 4DOS made me really happy in
    that respect.

    Please don't tell me I can realize this functionality with internal
    functions, plugins or whatever: I know that. It is simply tedious in
    some cases.

    * Klaus Meinhard *
    4DOS Info - Info for DOS
    www.4dos.info
     
  8. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    K_Meinhard wrote:
    | Steve Fabian wrote:
    || IMHO it would be disastrous to change @DOW to return the
    || ISO 8601 value when parameter 2 is set to 4, as it would break all
    || existing batch files which use it. A far better idea is to ADD a new
    || function @ISODOW, which could be a simple user defined function
    || (using the default definition of ParameterChar):
    ||
    || function isodow=`%@if[%@dow[%$] EQ 0,7,%@dow[%$]]`
    ||
    || UNTESTED!

    | VERY!!!
    |
    | I think you mean %@DOWI, which now shows 1=Sun, 2=Mon...3=Sat. It
    | doesn't show 0 for any day.

    Sorry, my memory failed (and I made the mistake of not looking up the
    definition of @DOWI). The principle isstill valid, though.

    | Nobody ever proposed to change that. All I (and probably others) would
    | like to see is an @ISODOWI giving 1=Mon, 2=Tue, 7=Sun.

    Sorry, you wrote earlier in this thread:

    ||| I'd like to see the other vars and functions claiming to give ISO 8601
    ||| output really do so...

    which I misinterpreted to include @DOWI.

    No objection to the extra function.

    The only variable claiming compliance is _isodate, and functions @makedate,
    @agedate, and @filedate. All of them in fact comply. In all of these
    functions you need to specify the second parameter as 4, of course (unless
    you set Windows' default date format to yyyy-mm-dd, in which case it becomes
    the TCC default). Excepting the 3 above functions and @DOW all other date
    functions return only a part of the date, thus ISO 8601 is irrelevant.

    | and I'd like to see an %@ISOWOY and %_ISOWOY.

    No objection.
    |
    | Please don't tell me I can realize this functionality with internal
    | functions, plugins or whatever: I know that. It is simply tedious in
    | some cases.

    No, I agree that there are many users for whom availability of these
    features internally would be very advantageous. There are also users, or
    potential users, who could benefit from a generic WOY function, which would
    allow the user to specify the day when the week starts, and also the rule
    for determining the first week of the year.
    --
    Steve
     
  9. K_Meinhard

    Joined:
    May 20, 2008
    Messages:
    310
    Likes Received:
    0
    Steve FXbiXn wrote:



    No, but @day, @month should return 2-digit , @year 4-digit results with
    the 4 modifier, IMHO.

    Mit freundlichem Gruß,

    Klaus Meinhard
     
  10. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    K_Meinhard wrote:
    | No, but @day, @month should return 2-digit , @year 4-digit results
    | with
    | the 4 modifier, IMHO.

    Here the display in 4nt6, 4nt7, 4nt8, tcc9 from the command
    echo %@year[%_isodate,4] %@month[%_isodate,4] %@day[%_isodate,4]
    is
    2008 9 9

    All are the correct numeric values. I have yet to see a calendar with month
    01 or day 02, not even my Siemens cellphone (made in China). Possibly a
    separate option, specified by an optional 3rd parameter or by the = syntax
    of @EVAL could be added to control output formatting; if so, it should be
    done for all functions which return a numeric value, including @inc and
    @dec, since formatting numeric output for tabular display or as a
    fixed-width suffix are very common usages.
    --
    Steve
     
  11. K_Meinhard

    Joined:
    May 20, 2008
    Messages:
    310
    Likes Received:
    0
    Steve FXbiXn wrote:


    I disagree. If I want single digit output from day and month, I have
    e.g. the default setting.

    [C:\]echo %@year[08-01-01,4]
    08

    @year returns just what was put in. As you explained yourself, the
    second parameter just tells TCC how to regard the input format. I would
    prefer very much it meant how to format the output.

    Mit freundlichem Gruß,

    Klaus Meinhard
     
  12. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    K_Meinhard wrote:
    | Steve FXbiXn wrote:
    |
    |
    |
    | ---Quote---
    || Here the display in 4nt6, 4nt7, 4nt8, tcc9 from the command
    || echo %@year[%_isodate,4] %@month[%_isodate,4] %@day[%_isodate,4]
    || is
    || 2008 9 9
    ||
    || All are the correct numeric values. I have yet to see a calendar with
    || month 01 or day 02, not even my Siemens cellphone (made in China).
    || Possibly a separate option, specified by an optional 3rd parameter or
    || by the = syntax of @EVAL could be added to control output formatting;
    || if so, it should be done for all functions which return a numeric
    || value, including @inc and @dec, since formatting numeric output for
    || tabular display or as a fixed-width suffix are very common usages.
    | ---End Quote---
    | I disagree. If I want single digit output from day and month, I have
    | e.g. the default setting.
    |
    | [C:\]echo %@year[08-01-01,4]
    | 08
    |
    | @year returns just what was put in.

    @year processed your input exactly as you specified. GIGO - garbage in,
    garbage out! You lied to the command processor - you told it the input is
    already in ISO 8601 format, but it was not. It still gave you a reasonable
    output, conformant to ISO 8601 to the same degree as the input. Do not blame
    the program it did not fix your mistake - should it have returned an error
    message?

    } As you explained yourself, the
    | second parameter just tells TCC how to regard the input format. I
    | would prefer very much it meant how to format the output.

    You would loose the ability to specify the input format, far more important
    for portability.

    I have already proposed that a method to specify the output format should be
    added to all functions returning a number. However, it may not have fixed
    the issue in your example - if you explicitly tell a program which rule to
    use to parse your input, but your actual input does not match the rule you
    specified, GIGO still applies.

    You are looking for the DWIM parser!
    --
    Steve
     
  13. K_Meinhard

    Joined:
    May 20, 2008
    Messages:
    310
    Likes Received:
    0
    Steve FXbiXn wrote:


    Ach Steve - I already control the input format while I write a batch,
    and if I don't like it or suspect that TCC might misinterprete it, I
    have ample tools to change it.

    It's a completely different thing when you set a batch free into the
    world: dates come in different input formats, according to country
    settings. I want a way to tell TCC to give me a certain, namely ISO,
    output format from the country specific input. If I don't know a batch
    is used in America beforehand, I need not tell date functions to use the
    1 parameter to expect that.


    That's nice.


    That's getting tedious. I know by now that the second par is seen only
    as indicating the input format. What I'm after is control of the output
    format ( and a few ISO compliant vars and functions). I think by now we
    want the same things, so lets not quibble over hairsplittings.


    TCC gives me

    C:\>echo %@makedate[%@date[01.01.08],4]
    2008-01-01

    but

    C:>echo %@year[01.01.08,4]
    01

    and

    C:>echo %@year[08.01.01,4]
    08

    So @makedate produces an ISO compliant result from my country-specific
    input, but @year sees 4 simply as a hint for the input format, does no
    checking and correcting. I simply see no practical use.

    Mit freundlichem Gruß,

    Klaus Meinhard
     
  14. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    K_Meinhard wrote:
    | Steve Fabian wrote:
    || You would loose the ability to specify the input format, far more
    || important for portability.

    | Ach Steve - I already control the input format while I write a batch,
    | and if I don't like it or suspect that TCC might misinterprete it, I
    | have ample tools to change it.

    Not if your program is portable, unless all its "input" is under its
    control.

    | It's a completely different thing when you set a batch free into the
    | world: dates come in different input formats, according to country
    | settings. I want a way to tell TCC to give me a certain, namely ISO,
    | output format from the country specific input. If I don't know a batch
    | is used in America beforehand, I need not tell date functions to use
    | the 1 parameter to expect that.

    The example you have below does the default to ISO conversion. For current
    date you already have _isodate. You need to remember also that the physical
    location of a machine does not mean it is set to use the local formats - I
    am in the USA, but my systems have defaulted to the ISO 8601 format since
    Win95, though I switched to the Hungarian field separator, the period, a
    couple of years ago (for both date and time). In any case, it is not
    difficult to convert from local to ISO format at the beginning of any
    routine, do all the work in a known format, and display the final results in
    the user's default formats. This is trivial. Your program is still fully
    portable.

    || I have already proposed that a method to specify the output format
    || should be added to all functions returning a number.

    | That's nice.

    || However, it may
    || not have fixed the issue in your example - if you explicitly tell a
    || program which rule to use to parse your input, but your actual input
    || does not match the rule you specified, GIGO still applies.
    | ---End Quote---
    | That's getting tedious. I know by now that the second par is seen only
    | as indicating the input format. What I'm after is control of the
    | output format ( and a few ISO compliant vars and functions). I think
    | by now we want the same things, so lets not quibble over
    | hairsplittings.
    |
    |
    | TCC gives me
    |
    | C:\>echo %@makedate[%@date[01.01.08],4]
    | 2008-01-01
    |
    | but
    |
    | C:>echo %@year[01.01.08,4]
    | 01
    |
    | and
    |
    | C:>echo %@year[08.01.01,4]
    | 08
    |
    | So @makedate produces an ISO compliant result from my country-specific
    | input, but @year sees 4 simply as a hint for the input format, does no
    | checking and correcting. I simply see no practical use.

    The most common values for the input format descriptor in my use have been
    0, i.e., default (usually not even specified), and 4, ISO. But today I wrote
    a data entry program which will be used by Americans. The raw data (images
    of text and photographs) has one date field in mon d, yyyy and another field
    in mm/dd/yyyy form. To allow testing it on my system I had to use format 1
    explicitly, and force year display to 4 digits. Here is a case when the
    format code is required.

    Whether or not the second parameter, specifying the parsing rule for the
    first parameter, has practical use in your world, it is not feasible to
    throw it away and make all existing aliases and batch programs which do
    depend on it fail. One guiding principle I always used is BACKWARD
    COMPATIBILITY. OTOH, adding an extra feature for explicit control of output
    format is backward compatible.

    In your examples above you keep using garbage input and expect the DWIM
    parser to make it valid!

    BTW, you know that @DATE and @MAKEDATE are limited to 1980..2079 for 2-digit
    year, and to 1980..2099 with 4-digit year. Cf. @makeage/@agedate, lower
    limit is 1601, upper limit beyond any useful dates.
    --
    Steve
     
  15. K_Meinhard

    Joined:
    May 20, 2008
    Messages:
    310
    Likes Received:
    0
    Steve FXbiXn wrote:


    Fine, So you have a need for the existing method to tell TCC how to see
    the input. Now let's concentrate on getting a method to control the
    output.


    Okay. So be it if you really need the input control. I think there are
    easier ways.


    No <sigh>. I used the native german date format to show that @year
    doesn't produce ISO output, (small wonder since the second parameter
    only tells @year which input field is the day, month, year, and no ISO
    formatting is applied) contrary to (at least my) expectations. I hoped
    that might demontrate the need for a mechanism to control the output
    format.

    If implemented, care should be taken to really produce ISO compliant
    output.

    Mit freundlichem Gruß,

    Klaus Meinhard
     
  16. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    K_Meinhard wrote:
    | Fine, So you have a need for the existing method to tell TCC how to
    | see
    | the input. Now let's concentrate on getting a method to control the
    | output.
    | ...
    | Okay. So be it if you really need the input control. I think there are
    | easier ways.

    True, but it is too late to do that. What's there works.
    |
    |
    |
    | ---Quote---
    || In your examples above you keep using garbage input and expect the
    || DWIM parser to make it valid!
    | ---End Quote---
    | No <sigh>. I used the native german date format

    and specified that you used ISO format - a mistake (too be charitable), or a
    lie.

    | to show that @year
    | doesn't produce ISO output, (small wonder since the second parameter
    | only tells @year which input field is the day, month, year, and no ISO
    | formatting is applied) contrary to (at least my) expectations. I hoped
    | that might demontrate the need for a mechanism to control the output
    | format.

    I have several rounds of posts ago conceded your point about the need, or at
    least the desirability, of explicit output format control, and the its lack
    in the current implementation. I refuse to call the current implementation
    wrong or incorrect, it never made the claim to provide the output format you
    wish. A program is incorrect only if it does not do what it claims to do.
    JPsoft products do exactly what they claim to do (at least in this
    particular area, I am not claiming that they are perfect, though I do not
    recall any significant difference between operation and documentation,
    making them at least "near perfect"). If a specific user (or group of users)
    wants a program to do something that it does not do may be a shortcoming, at
    least from the group's point of view. If the group is large enough, vocal
    enough, i.e., influential enough, the desired feature might be added. If the
    demand is made by claiming that without the feature the product is faulty
    many developers might become upset with those making the claim, and decide
    to spite them regardless of the technical or even the financial merits of
    the requested feature.
    |
    | If implemented, care should be taken to really produce ISO compliant
    | output.

    This whole discussion should be in the TC Suggestions forum. That is where
    you should submit a detailed list of desired features, retaining backward
    compatibility, i.e., existing aliases and programs written to be executed by
    4nt or tcc MUST behave as they do now after the features are implemented.
    New variable functions and new internal variables obviously qualify.
    Additional values for parameters of an enumeration type, e.g., the date
    format codes, such as the new value 5 implemented by Luchezar Georgiev in
    4DOS to specify a date in the ISO year-week-day format (2008-W03-5) are also
    backward compatible. Adding an optional extra parameter to a function call
    is also backward compatible, if it can be easily disambiguated.

    Hope this will satisfy your desires, and you will submit your suggestion.
    --
    Steve
     
  17. K_Meinhard

    Joined:
    May 20, 2008
    Messages:
    310
    Likes Received:
    0
    Steve,

    I don't know what's bitten you. I don't like your tone:


    TCMD help states:


    For date formats:


    Commands and functions which accept a date as a parameter expect the
    same field order displayed by the DIR command and functions returning a
    date without a format code specifier. The year can be entered as a
    4-digit or 2-digit value. Two-digit years from 80 to 99 are interpreted
    as 1980...1999; values from 0 to 79 are interpreted as 2000...2079.
    Month and day may be entered without a leading zero. Most non-numeric
    printing characters are accepted as field separators. All three fields
    must be specified. <

    There is no clear statement that the second, optional parameter defines
    the input format. The Date Input Formats page mentions only what happens
    in their absence. So perhaps my initial error is understandable.

    Since then I have accepted that this is so, even if I find it
    regrettable. Since then also I have tried to show that control of the
    output format is desirable and useful, a wish you have supported.

    I doubt that our quibbling will make Rex more amenable to implement this
    wish.


    Perhaps you could call it suboptimally thought out and researched? As
    shown above there is also no claim in the docs that support your
    position. The facts do so, however, yes.


    Have you any personal stakes in this? I have conceded my error, I have
    shown that even the help documentation isn't very clear, and that I wish
    for something more. I haven't claimed TCMD is faulty. I have said that I
    am astonished that something so elementary as the ISO date standards,
    that are a, AFAIK, worldwide business standard and basis of every
    european calendar I know, are, IMHO, not very well implemented. That
    this starts with the wrong ISO number is an aside.


    Everybody who wants to take note has long so done so. I see no need to
    repeat this in another forum. For me this thread is closed.

    Mit freundlichem Gruß,

    Klaus Meinhard
     

Share This Page