ISO 8601 support

[K_Meinhard]

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

 

[Steve Fabian]

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

 

[K_Meinhard]

Steve,

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

> 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:

Ah, now I see.

> 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 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 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).

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

 

[Steve Fabian]

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

 

[K_Meinhard]

Steve FXbiXn 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

> 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.

Mit freundlichem Gruß,

Klaus Meinhard

 

[Steve Fabian]

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

 

[K_Meinhard]

Steve FXbiXn 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.

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

 

[Steve Fabian]

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

 

[K_Meinhard]

Steve FXbiXn wrote:

> > > > 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, but @day, @month should return 2-digit , @year 4-digit results with
the 4 modifier, IMHO.

Mit freundlichem Gruß,

Klaus Meinhard

 

[Steve Fabian]

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

 

[K_Meinhard]

Steve FXbiXn wrote:

> 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.

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

 

[Steve Fabian]

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

 

[K_Meinhard]

Steve FXbiXn 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.

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.

> 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.

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

 

[Steve Fabian]

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

 

[K_Meinhard]

Steve FXbiXn wrote:

> > 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.

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.

> 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.

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

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

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

 

[Steve Fabian]

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

 

[K_Meinhard]

Steve,

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

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

TCMD help states:

> @YEAR[date[,format]]: Returns the year for the specified date. See
> date formats for valid formats. @YEAR accepts an optional second
> parameter specifying the date format: <

For date formats:

> Date Input 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.

> I refuse to
> call the current implementation wrong or incorrect, it never made the
> claim to provide the output format you 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.

> 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.

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.

> Hope this will satisfy your desires, and you will submit your
> suggestion.

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