Is TimeSpan predefined .Net type?

[Alexander]

Hi.

Why Convert class converts all predefined .NET types to
each other (DateTime also converted), but for TimeSpan
generate exception. I think TimeSpan is the same base
..NET type as DateTime. May be .NET creators forget add
TimeStamp to Convert class and TypeCode enum?

Shanks.

 

[Jon Skeet]

Why Convert class converts all predefined .NET types to
each other (DateTime also converted)

What do you mean by "predefined .NET type"?

but for TimeSpan generate exception. I think TimeSpan is the
same base .NET type as DateTime.

No it's not - what makes you think it is?

May be .NET creators forget add
TimeStamp to Convert class and TypeCode enum?

DateTime implements IConvertible. TimeSpan doesn't. Arguably this was a
bad move, but it's not just a case of someone making a typo.

 

[Alexander]

Hi Jon

What do you mean by "predefined .NET type"?

Look at TypeCode enum and Type.IsPrimitive.

No it's not - what makes you think it is?

I don't see any fundamental difference between
DateTime and TimeSpan. You can look at DateTime
as TimeSpan from zero to current date. May be
..NET developers think differently.

 

[Jon Skeet]

Look at TypeCode enum and Type.IsPrimitive.

Well Type.IsPrimitive doesn't list *either* DateTime *or* TimeSpan.

DateTime is in the TypeCode enumeration because it implements
IConvertible. TimeSpan isn't because it doesn't.

I don't see any fundamental difference between
DateTime and TimeSpan.

One is a point in time, another is the amount of time between two
points. They are as different as "New York" and "5000 miles".

You can look at DateTime as TimeSpan from zero to current date.

You can, but I don't see why it would be particularly useful to do so.
It certainly doesn't mean that they're "the same base type" - whatever
you meant exactly by that. What exactly *did* you mean by it?

 

[ncaHammer]

Why Convert class converts all predefined .NET types to
each other (DateTime also converted), but for TimeSpan
generate exception.

Design fault, IMHO

I think TimeSpan is the same base
.NET type as DateTime.

I agree, since it is part of DateTime signature (Subtraction and Addition
operators require TimeSpan) their is no doubt about it

May be .NET creators forget add
TimeStamp to Convert class and TypeCode enum?

Yes, that's my impression too. I hope that this get fixed in a future
version. I hate that i had to introduce special cases in my app just to
provide a IConvertible support for it

 

[Jon Skeet]

I agree, since it is part of DateTime signature (Subtraction and Addition
operators require TimeSpan) their is no doubt about it

No doubt about what, exactly? I don't know exactly what Alexander means
by "TimeSpan is the same base .NET type as DateTime" but it sounds
unlikely that he'd come up with a definition which would actually fit
the quote in any true and meaningful sense.

They're both value types, and they certainly relate to each other in
semantics, but not in terms of actual type definition.

So, what do you understand Alexander to mean by "TimeSpan is the same
base .NET type as DateTime"?

 

[ncaHammer]

So, what do you understand Alexander to mean by "TimeSpan is the same
base .NET type as DateTime"?

Well i try to define it (sorry for my bad English in advance)


1) Timespan is in fact a long (Int64) making most System.Convert methods to
able to convert it without any loss (following the same rules as Int64). ie
the Int64.ToTimeSpan (if existed) would be just a

return new TimeSpan(m_value);

IIRC the Int64.ToDateTime fails with an invalid cast error
(meaning Timespan is more IConvertible than DateTime<g>)

2) Operators Addition, Subtraction, Unary (already defined), multiplication
and division make sense on this Type (in contrast with DateTime), making
expressions (that using it) to carry no ambiguity to the reader

3) "base Types" (as OP said) defined in the TypeCode enumeration.
That enumeration defines a closed set of types, any operation between those
types must accept or return a type that is already defined in that set.
That rule (orthogonal) is breaking by TimeSpan type (or DateTime type)
since operations on DateTime (+ and - ) require a TimeSpan


CLR tries to correct this breaking rule, in some persistence frameworks :

4) System.Data.DataColumn.DataType
Accepted types are "base types" + TimeSpan

5) System.XML.XMLConvert
Converts from/to "base types" + TimeSpan

 

[Jon Skeet]

Well i try to define it (sorry for my bad English in advance)

1) Timespan is in fact a long (Int64) making most System.Convert methods to
able to convert it without any loss (following the same rules as Int64).

When you say it "is in fact a long" - it's *not*, it just happens to
only contain a single field, which is a long.

ie the Int64.ToTimeSpan (if existed) would be just a

return new TimeSpan(m_value);

Well, it could be, yes.

IIRC the Int64.ToDateTime fails with an invalid cast error
(meaning Timespan is more IConvertible than DateTime<g>)

I don't think taking into account a method which doesn't exist really
counts as being more convertible

2) Operators Addition, Subtraction, Unary (already defined), multiplication
and division make sense on this Type (in contrast with DateTime), making
expressions (that using it) to carry no ambiguity to the reader

Sure - so that's a big *difference* between DateTime and TimeSpan, so
in what way are they "the same base type"?

3) "base Types" (as OP said) defined in the TypeCode enumeration.
That enumeration defines a closed set of types, any operation between those
types must accept or return a type that is already defined in that set.

Where do you get that idea? I haven't seen anything like that.

That rule (orthogonal) is breaking by TimeSpan type (or DateTime type)
since operations on DateTime (+ and - ) require a TimeSpan

CLR tries to correct this breaking rule, in some persistence frameworks :

4) System.Data.DataColumn.DataType
Accepted types are "base types" + TimeSpan

5) System.XML.XMLConvert
Converts from/to "base types" + TimeSpan

In what way does that make TimeSpan and DateTime "the same base type"?

 

[ncaHammer]

In what way does that make TimeSpan and DateTime "the same base type"?

You keep insisting on this ! ;-)
What OP means is that TimeSpan is also a base type as DateTime is !
or if DateTime implements IConvertible, TimeSpan should also

Try to compute an average on Dates without using a TimeSpan (in any
language)
In fact DateTime is totally depended from TimeSpan for any computation !

but as Alexander said ".NET creators forget add TimeStamp to Convert class
and TypeCode enum" and i totally agree with him

That's a design fault

 

[Jon Skeet]

You keep insisting on this ! ;-)
What OP means is that TimeSpan is also a base type as DateTime is !

How do you know? That's not what he actually said, and he hasn't
clarified it at all...

or if DateTime implements IConvertible, TimeSpan should also

Try to compute an average on Dates without using a TimeSpan (in any
language)
In fact DateTime is totally depended from TimeSpan for any computation !

Sure - but that doesn't necessarily mean it needs to implement
IConvertible.

but as Alexander said ".NET creators forget add TimeStamp to Convert class
and TypeCode enum" and i totally agree with him

That's a design fault

Well, it's more that they didn't make it implement IConvertible -
*that's* what determines whether something should have methods in the
Convert class and an entry in the TypeCode enumeration.

I can see it would be handy, but I'm not that fussed either way. I
think it's actually more important that in a future version there's a
TimeSpan.ToString method which takes a format specifier, but there we
go.