×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
But in the _given scenario_ that part of the date comes from a
literal 0101 versus any possible bad inputs such as the 1315; i.e.
no possibility of anything but the day-Month value of 01-Jan given
the /literal\hard-coded/ input. Thus an unmonitored exception for
any error on the date conversion is probably the ideal choice; i.e.
an error should never occur, so an unmonitored exception is left to
the HLL or user-coded generic handler to diagnose. Noting however,
that the four characters of input for the year as '0000' would need
to be diagnosed as an error [prior to date conversion] since that
input will validly convert to the integer zero, but of course zero
is invalid for the year portion in a date conversion from [the
string equivalent of] '0000-01-01'.
Regards, Chuck
Luis Rodriguez wrote:
<<SNIP>>
Also, Would it not better to monitor your date conversion? I can
think of a lot of scenarios where the number is right but the
date is wrong (eg. 13152010).
David FOXWELL wrote:
<<SNIP>>
In fact, as I receive the date as 4 characters, I will convert
it to integer and monitor for that. I will then compose my date
field but not monitor the conversion of my date field.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.