Dates As Function Parameters - Why so Convoluted?

[Jordan]

I'm working with a Repeater using a custom function inside the
<itemtemplate> to return a text string. The parameters SHOULD be (DateTime,
DateTime, Int16) but the difficulties in getting DateTimes to be evaulated
is odd. It's much easier to do (String, String, Int16) and convert the
Strings back and forth to dates to compare. I'm also expecting that the 2nd
DateTime parameter will be "null" at times and want to detect that.

[Question]
I'm just curious why the DateTime datatype is much more convoluted in it's
use.

To get the parameters to work at all, I had to use
(DateTime.Parse(Databinder...).ToString()) - why couldn't I just use the
(datetime) Databinder...? I'm just getting into DateTime datatypes too, so
maybe it's just expereince I need.

[Craig Deelsnyder]

Jordan wrote:

I'm working with a Repeater using a custom function inside the
<itemtemplate> to return a text string. The parameters SHOULD be (DateTime,
DateTime, Int16) but the difficulties in getting DateTimes to be evaulated
is odd. It's much easier to do (String, String, Int16) and convert the
Strings back and forth to dates to compare. I'm also expecting that the 2nd
DateTime parameter will be "null" at times and want to detect that.

[Question]
I'm just curious why the DateTime datatype is much more convoluted in it's
use.

To get the parameters to work at all, I had to use
(DateTime.Parse(Databinder...).ToString()) - why couldn't I just use the
(datetime) Databinder...? I'm just getting into DateTime datatypes too, so
maybe it's just expereince I need.

Well, it really is a more complex type. Meaning doing a simple cast
from a string to an int is pretty simplistic, either it's numeric or not
and the conversion happens. Wherease dates are very localized and need
alot of validation based on the current locale, delimiters used, etc. I
think it's just to get this point across, it's not as simple as
converting a string to an int.

--
Craig Deelsnyder
Microsoft MVP - ASP.NET

[Jordan]

> Well, it really is a more complex type. Meaning doing a simple cast

from a string to an int is pretty simplistic, either it's numeric or not
and the conversion happens. Wherease dates are very localized and need
alot of validation based on the current locale, delimiters used, etc. I
think it's just to get this point across, it's not as simple as
converting a string to an int.

That's understandable, but why doesn't the DateTime have a operator
for NULL comparison? I guess that's my real concern. Applying the same
understanding of nulls and matching them to dates... I don't see why it
would
be different than a NULL string. NULL is undeterministic regardless of it's
assumed datatype. A NULL date should equal a NULL string.

j

[John Saunders]

"Jordan" <jf*****@learn.colostate.edu> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

Well, it really is a more complex type. Meaning doing a simple cast
from a string to an int is pretty simplistic, either it's numeric or not
and the conversion happens. Wherease dates are very localized and need
alot of validation based on the current locale, delimiters used, etc. I
think it's just to get this point across, it's not as simple as
converting a string to an int.
That's understandable, but why doesn't the DateTime have a operator
for NULL comparison? I guess that's my real concern. Applying the same
understanding of nulls and matching them to dates... I don't see why it
would
be different than a NULL string. NULL is undeterministic regardless of

it's assumed datatype. A NULL date should equal a NULL string.

Are you referring to NULL as a database concept? If you are, be aware that
normal types don't deal with NULL. Instead, a NULL value is represented as
an object of type DBNull.

--
John Saunders
John.Saunders at SurfControl.com

[Jordan]

> Are you referring to NULL as a database concept? If you are, be aware that

normal types don't deal with NULL. Instead, a NULL value is represented as
an object of type DBNull.

That depends. The actual value is coming from a Sproc and so yes, the object
type
could be a DBNull...but that doesn't "help" me understand why
getting/evaulating a DBNull
into a String datatype is any different than getting/evaulating a DBNull
into a DateTime
datatype.

If I expected a NULL value, then I would certainly use the DBNull structure,
but I don't
know what I'm getting except that it's either a Date or a NULL.

j

[John Saunders]

"Jordan" <jf*****@learn.colostate.edu> wrote in message
news:%2******************@TK2MSFTNGP10.phx.gbl...

Are you referring to NULL as a database concept? If you are, be aware that normal types don't deal with NULL. Instead, a NULL value is represented as an object of type DBNull.
That depends. The actual value is coming from a Sproc and so yes, the

object type
could be a DBNull...but that doesn't "help" me understand why
getting/evaulating a DBNull
into a String datatype is any different than getting/evaulating a DBNull
into a DateTime
datatype.

If I expected a NULL value, then I would certainly use the DBNull structure, but I don't
know what I'm getting except that it's either a Date or a NULL.

Take a look at Convert.IsDBNull. It should work for many types.

BTW, what language are you using? I would guess VB.NET with Option Strict
Off, so that it's letting you get away with murder (i.e., without
understanding what's going on).
--
John Saunders
John.Saunders at SurfControl.com

[Jordan]

> Take a look at Convert.IsDBNull. It should work for many types.

BTW, what language are you using? I would guess VB.NET with Option Strict
Off, so that it's letting you get away with murder (i.e., without
understanding what's going on).

Cool, will do. I've used Convert before, but not for IsDBNull yet.

I'm using C# via ASP.NET. Explicit is on by default, but I'm not certiain
if that's the same as Option Strict for VB.NET (unless you mean Explicit too
or
MS changed it?)

j