ISO 8601 plugin enhancement

[Steve Fabian]

A very useful additional output format for date, time and timestamp information would be that of the internal variable _DATETIME, i.e., zero-padded fixed width elements in hierarchical order, NO separators. A single new output format code could serve all cases, e.g., 260.

In many of my TCC programs I need all of the individual elements of date and time ("now", a past event or a filestamp) in fixed-width format, one at a time. It is very time consuming (esp. with @FILESTAMP) to obtain them individually. I usually obtain the date and time once, save it in a variable, and parse it. A method that makes all of them accessible at once would save lots of work. Here are some possible ways of doing it:
1/ setting elements of a previously defined array whose name is provided by the user
2/ setting internal variables for each element
3/ setting elements of an array defined when the plugin is loaded
The advantage of methods 2 and 3 is that they could be done ALWAYS, transparently to the user.

A very useful function would convert AM/PM to 24-h time. Currently I use a cumbersome batch file, invoked by a UDF - very slow! Just an enhanced version of the built-in @TIME function to accept 12-h time would be sufficient - I could just use %@maketime[%@time[x]] to perform the desired conversion.

Note: Thanks for your plugins! Great timesavers!
--
Steve

 

[Charles Dye]

A very useful additional output format for date, time and timestamp information would be that of the internal variable _DATETIME, i.e., zero-padded fixed width elements in hierarchical order, NO separators. A single new output format code could serve all cases, e.g., 260.

@FILESTAMP already has a format (276) to return the whole thing as 14 digits. For most of the date functions, though, I don't think it would make much sense since most of them only return a date -- not a time.

In many of my TCC programs I need all of the individual elements of date and time ("now", a past event or a filestamp) in fixed-width format, one at a time. It is very time consuming (esp. with @FILESTAMP) to obtain them individually. I usually obtain the date and time once, save it in a variable, and parse it. A method that makes all of them accessible at once would save lots of work. Here are some possible ways of doing it:
1/ setting elements of a previously defined array whose name is provided by the user
2/ setting internal variables for each element
3/ setting elements of an array defined when the plugin is loaded
The advantage of methods 2 and 3 is that they could be done ALWAYS, transparently to the user.

A generic command to unpack a string into array variables might be useful for more that that. (It would be cool if Rex gave us hooks to manipulate array variables (and pointers to array variables!) directly; at present I think we have to call ExpandVariables and Set_Cmd, much like a batch file.) I'll think about it, though it might turn out to be a different plugin altogether!

A very useful function would convert AM/PM to 24-h time. Currently I use a cumbersome batch file, invoked by a UDF - very slow! Just an enhanced version of the built-in @TIME function to accept 12-h time would be sufficient - I could just use %@maketime[%@time[x]] to perform the desired conversion.

Something like this, perhaps?
http://www.unm.edu/~cdye/plugins/iso8601.html#f_timefmt

 

[Steve Fabian]

From: Charles Dye
| From: Steve Fabian
|| A very useful additional output format for date, time and timestamp
|| information would be that of the internal variable _DATETIME, i.e.,
|| zero-padded fixed width elements in hierarchical order, NO
|| separators. A single new output format code could serve all cases,
|| e.g., 260.
|
| @FILESTAMP already has a format (276) to return the whole thing as 14
| digits. For most of the date functions, though, I don't think it
| would make much sense since most of them only return a date -- not a
| time.

Thanks, I was apparently still using an older version. You and Vince are sometimes even harder to keep up with than Rex!

However, I'd suggest that you allow output format 276 in all functions reporting a date, a time, or a date-and-time, as it is often useful to report them without separators. For example, to support some old-old-old utilities, I sometimes create 8.3 directory and file names. A date without punctuation is a perfect directory name; a time likewise a perfect name to use before an extension. At
other times (to reduce directory count) my directory is YYYYMM, and file name DDHHMMSS. Both are easily split out of a 14-digit timestamp.

|| In many of my TCC programs I need all of the individual elements of
|| date and time ("now", a past event or a filestamp) in fixed-width
|| format, one at a time. It is very time consuming (esp. with
|| @FILESTAMP) to obtain them individually. I usually obtain the date
|| and time once, save it in a variable, and parse it. A method that
|| makes all of them accessible at once would save lots of work. Here
|| are some possible ways of doing it:
|| 1/ setting elements of a previously defined array whose name is
|| provided by the user
|| 2/ setting internal variables for each element
|| 3/ setting elements of an array defined when the plugin is loaded
|| The advantage of methods 2 and 3 is that they could be done ALWAYS,
|| transparently to the user.
|
| A generic command to unpack a string into array variables might be
| useful for more that that. (It would be cool if Rex gave us hooks to
| manipulate array variables (and pointers to array variables!)
| directly; at present I think we have to call ExpandVariables and
| Set_Cmd, much like a batch file.) I'll think about it, though it
| might turn out to be a different plugin altogether!

Yes, a command to tokenize a text line into an array in the manner each token can be found with @FIELD or @WORD would be very useful. This would be esp. nice if a file containing e.g. CSV formatted data could be spread into a 2-D array by a single command or function.

|| A very useful function would convert AM/PM to 24-h time. Currently I
|| use a cumbersome batch file, invoked by a UDF - very slow! Just an
|| enhanced version of the built-in @TIME function to accept 12-h time
|| would be sufficient - I could just use %@maketime[%@time[x]] to
|| perform the desired conversion.
|
| Something like this, perhaps?
| http://www.unm.edu/~cdye/plugins/iso8601.html#f_timefmt

See above! Thanks for doing it already!
--
Steve

 

[Steve Fabian]

Testing @TIMEFMT in iso8601.dll of 2011-04-25 23:38:22, size 51,712, CRC=583C2670.

I used the @TIMEFMT function to generate 12 different am/pm formatted strings for 0:00, 1:00, 11:00, 12:00, 13:00 and 23:00 (this was performed correctly). The resulting strings were used as the input, with no tfmt parameter, to convert them back to 24-h format. Behold! Any 12-h format with space between the numbers and letter failed abysmally. An error report "Invalid time format" was delivered, and the value of the last correct conversion to 24-hr format was returned (not affected by the result of the correct 24-h to 12-h conversion just performed).

Code:

@echo off
setlocal
do hr in /l 00 01 11 12 13 23
set t=%hr:00
do f = 1 to 12
set t12=%@timefmt[%t,%f]
set t24=%@timefmt[%t12]
echo %@f2[%f] %t %t24 %t12
enddo
enddo
--
Steve

 

[Charles Dye]

Behold! Any 12-h format with space between the numbers and letter failed abysmally. An error report "Invalid time format" was delivered, and the value of the last correct conversion to 24-hr format was returned (not affected by the result of the correct 24-h to 12-h conversion just performed).

For compatibility reasons, the function preparser splits args at unquoted spaces. I'll fix that in the new functions. But in @MAKEAGE, you're just going to have to quote any times that might contain spaces.

 

[Steve Fabian]

---- Original Message ----
| For compatibility reasons, the function preparser splits args at
| unquoted spaces. I'll fix that in the new functions. But in @MAKEAGE,
| you're just going to have to quote any times that might contain
| spaces.

I don't plan on using am/pm with anything but @TIMEFMT, so this is not important. BTW, I did not test it, but do all age, date and time functions accept in thier inputs any non-decimal character as element separators, as the ones built into TCC do?

I often switch between English and Hungarian keyboards, which also affect the date, time and decimal separators. Any chance of explicitly specifying them? Could be done as optional extra parameters.

BTW, I think the LONGYEARS command could be enhanced (or a new command added) to change the defaults for each option, in the manner of SETDOS /C etc. If one uses the same formatting options in a loop, often thousands of times, this ought to allow faster function execution due to the elimiation of optional parameter parsing time.

You might wish to refer to day count relative to 1970-01-01 as Unix.

And again, thanks for a most useful tool.
--
Steve

 

[Steve Fabian]

Two additional points.

Isn't the ISO8601 separator of date and time capital T, e.g., 2011-06-30T08:27:30? It should be an option where applicable.

In the help page "What Is Not Supported" change
from: "The new date formats are not supported in date ranges in file-handling commands."
to: "Date ranges in the file-handling commands of TCC do not support the new date formats."
--
Steve