.net 2.0 only error "Ticks must be between DateTime.MinValue.Ticks"

[John H]

Hi

Get this error
"Ticks must be between DateTime.MinValue.Ticks and
DateTime.MaxValue.Ticks"

on a web site we built on Visual Studio 2003 ( .net 1.1) but deploying
to .net 2.0.
It runs ok on .net 1.1

I have seen quite a few posts about this e.g

http://groups.google.com/group/micr...teTime.MaxValue.Ticks&rnum=1#f60046715a977609


but this and others indicate issue with .net 1.1 to .net 2.0
communication and incompatibility introduced into the DateTime and
remoting .
However our situation is not this but just our site running totally on
..net 2.0 only.
Any solutions/hot fixes/workaounds for this problem.

All info welcome.

Regards
JOhn

 

[Peter Bromley]

Hi

Get this error
"Ticks must be between DateTime.MinValue.Ticks and
DateTime.MaxValue.Ticks"

on a web site we built on Visual Studio 2003 ( .net 1.1) but deploying
to .net 2.0.
It runs ok on .net 1.1

I have seen quite a few posts about this e.g

http://groups.google.com/group/micr...teTime.MaxValue.Ticks&rnum=1#f60046715a977609


but this and others indicate issue with .net 1.1 to .net 2.0
communication and incompatibility introduced into the DateTime and
remoting .
However our situation is not this but just our site running totally on
.net 2.0 only.
Any solutions/hot fixes/workaounds for this problem.

All info welcome.

Regards
JOhn

I encountered this when attempting to run our server software with .NET
2.0 and our client software with .NET 1.1 (but the general error applies
in ever so many cases).

The issue is that the internal storage of DateTime has changed subtly
with .NET 2.0. The top two bits of the internal Int64 are now used to
indicated the DateTimeKind (Unspecified = 0, Local = 1, UTC = 2). Most
times now in .Net 2.0 will be Local or UTC which puts the Int64 ticks
value out of range from .NET 1.1's perspective.

My workaround was to force an Unspecified DateTimeKind by performing the
following magic when passing a DateTime across my client/server interface:

utcDateTimeValue = System:ateTime(UtcDateTimeValue.Ticks);

(I deal with UTC DateTime values only in the interface between my client
and server so losing the DateTimeKind causes no problems for a .NET 2.0
client).

I can't see what justification MS had for fundamentally changing a type
like this. Such a change can only be backward compatible and just breaks
in the general remoting case. And then they dont list it as a breaking
change for .NET 2.0. I think they really dropped the ball with this
change. It has such nasty implications for remoting and persistent
storage with mixed versions.

HTH,

Peter Bromley
ADInstruments Ltd

 

[John H]

Thanks very much for the info.