Re: New lexical function F$DELTA_TIME
From: Carl Perkins (carl_at_gerg.tamu.edu)
Date: 07/12/03
- Next message: Michael Austin: "Re: PPPOE? When? How?"
- Previous message: Tomasz Dryjanski: "Re: [spam] Looking for a DLT 7000 drive"
- In reply to: Carl Perkins: "Re: New lexical function F$DELTA_TIME"
- Next in thread: David J. Dachtera: "Re: New lexical function F$DELTA_TIME"
- Reply: David J. Dachtera: "Re: New lexical function F$DELTA_TIME"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: 12 Jul 2003 11:11 CDT
carl@gerg.tamu.edu (Carl Perkins) writes...
}In article <3F0F6573.D6BD3B9@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes...
}}John Santos wrote:
}}> On Thu, 10 Jul 2003, David J. Dachtera wrote:
}}> > Jim Strehlow wrote:
}}> > >
}}> > > Guy Peleg <guy.peleg@hp.com> wrote in message news:<3F0D7BFC.383CB534@hp.com>...
}}> > > ... with the next Alpha VMS version V7.3-2, we will ship a new
}}> > > lexical function F$DELTA_TIME ...
}}> > >
}}> > > Having optional parameters for
}}> > > (..., "day"|"hour"|"minute"|"second", variableName )
}}> > > would be "nice" to save us from parsing the result string;
}}> > > but we can parse if we have to do so.
}}> > >
}}> > > It would save us from writing an extra couple of lines of code (our own subroutine).
}}> >
}}> > Just tried these for fun...
}}> >
}}> > DJAS01::DDACHTERA$ say f$cvtime( "0 01:23:45.67", "delta" )
}}> > 0 001:23:45.67
}}>
}}> $ write sys$output f$cvtime( "2 01:23:45.67", "delta" )
}}> %DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format
}}> \2 01:23:45.67\
}}
}}Hhmmm...
}}
}}DJAS01::DDACHTERA$ say f$cvtime( "1 23:45:67.89", "delta" )
}}%DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format
}} \1 23:45:67.89\
}}
}}Well! Looks like we found a bug in F$CVTIME()!
}}
}}V7.2-2, BTW. What's yours?
}}
}}--
}}David J. Dachtera
}
}On 7.2-1, you see this interesting thing:
}
}$ write sys$output f$cvtime( "01:23:45.67", "delta" )
}0 01:23:45.67
}$ write sys$output f$cvtime( "001:23:45.67", "delta" )
}0 001:23:45.67
}$ write sys$output f$cvtime( "0001:23:45.67", "delta" )
}0 0001:23:45.67
}
}The formatting of the output fields matches the number of digits
}in the input fields. It isn't just the hour field either:
}
}$ write sys$output f$cvtime( "0001:023:0045.67", "delta" )
}0 0001:023:0045.67
}
}You are allowed to have a space in the hour filed if the first digit
}is a 0, but not anything else:
}
}$ write sys$output f$cvtime( "0 001:023:0045.67", "delta" )
}0 0001:023:0045.67
}$ write sys$output f$cvtime( "1 001:023:0045.67", "delta" )
}%DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format
} \1 001:023:0045.67\
}$ write sys$output f$cvtime( "1-001:023:0045.67", "delta" )
}1 001:023:0045.67
}
}And finally:
}
}$ write sys$output f$cvtime( "0001-0001:00023:00045.67", "delta" )
}0001 0001:00023:00045.67
}
}You can add one more digit before it gives an IVDTIME error (I expect
}it is from exceeding the maximum allowed string length for the input).
}
}How strange is that?
}
}--- Carl
Following up my own post, since I made a mistake.
Above I said "You are allowed to have a space in the hour filed if the first
digit is a 0, but not anything else" but that is not correct.
You can have a space in the hour field, as long as removing the space
makes it a valid hour:
$ write sys$output f$cvtime( "1 1:023:0045.67", "delta" )
0 11:023:0045.67
$ write sys$output f$cvtime( "2 1:023:0045.67", "delta" )
0 21:023:0045.67
$ write sys$output f$cvtime( "3 1:023:0045.67", "delta" )
%DCL-W-IVDTIME, invalid delta time - use DDDD-HH:MM:SS.CC format
\3 1:023:0045.67\
This failed because there are not 31 hours in the day. In the various
examples with non-zero first dgits from other people up above they
attempted 3 digit hours (with a space before the last two), which
is why they didn't work.
$ write sys$output f$cvtime( "0002 1:023:0045.67", "delta" )
0 00021:023:0045.67
The space is not a separator for the day, it is a space in the hour field.
For that matter, you can have spaces in any field:
$ write sys$output f$cvtime( "0002 1:0 23:00 45. 67", "delta" )
0 00021:023:0045.67
However any space between a number and the following colon become a zero:
$ write sys$output f$cvtime( "1 :01:45.67", "delta" )
0 10:01:45.67
$ write sys$output f$cvtime( "1 :01 :45.67", "delta" )
0 10:010:45.67
Likewise for a number and a following decimal point:
$ write sys$output f$cvtime( "1 :01 :5 .67", "delta" )
0 10:010:50.67
You should note that in a combination time you can't have a space
after the "+", but other than that one case spaces (and extraneous
leading zeros) in the delta portion don't seem to matter except
that spaces between the number and the following colon are treated
as zeros.
$ write sys$output f$cvtime("01-JAN-2222 +1-01 : 2 3: 45.67","absolute")
2-JAN-2222 10:23:45.67
$ write sys$output f$cvtime("01-JAN-2222 +1-01 : 2 3 : 45.67","absolute")
%DCL-W-IVATIME, invalid absolute time
\01-JAN-2222 +1-01 : 2 3 : 45.67\
$ write sys$output f$cvtime("01-JAN-2222 +1-01 : 2 : 45.67","absolute")
2-JAN-2222 10:20:45.67
Leading zeros in the numeric parts of an absolute time don't matter either:
$ write sys$output f$cvtime( "001-JAN-002222")
2222-01-01 00:00:00.00
$ write sys$output f$cvtime( "001-JAN-002222","ABSOLUTE")
1-JAN-2222 00:00:00.00
So it may be even stranger than it looked before, but it is strange in
a very orderly way. A space after the "+" in a combination time is invaid.
Spaces between a number and a following punctuation mark (colon or decimal
point) are converted to zeros. All other spaces are removed. The number
of digits remaining is the number of digits that will appear in the output
and this can be influenced by adding leading zeros to increase the size
of the field, or traling zeros in the hundredths of a second part.
$ write sys$output f$cvtime( "1:1:5.7", "delta" )
0 1:1:5.7
$ write sys$output f$cvtime( "001 : 1 : 005.700", "delta" )
0 0010:10:005.700
--- Carl
- Next message: Michael Austin: "Re: PPPOE? When? How?"
- Previous message: Tomasz Dryjanski: "Re: [spam] Looking for a DLT 7000 drive"
- In reply to: Carl Perkins: "Re: New lexical function F$DELTA_TIME"
- Next in thread: David J. Dachtera: "Re: New lexical function F$DELTA_TIME"
- Reply: David J. Dachtera: "Re: New lexical function F$DELTA_TIME"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|