Watch out if you're going to use option (a) (or DateTime.MaxValue) in web service; I had this problem before.
When you return DateTime, web service automatically converts your DateTime to UTC before transfer and then in client code to local time. You may not notice this while you're testing within single time-zone. The problem is that, converting MinValue/MaxValue to/from UTC may cause exception. There's logically no way to know if a DateTime is UTC or local, so what they do is simply add/subtract current time-zone offset. DateTime cannot hold values outside of Min/Max values and thus it'll raise exception. I think this is a design problem of web service code; they should not do this kind of conversion automatically. One can pass UTC date/time to web service if they want to, and this is too much service of web service infrastructure. With this "help", if data on your database is UTC, you must convert it to local time before sending back to client. Buy anyway, this is what we have today. So, use of MinValue/MaxValue in web service needs attention. -----Original Message----- From: dotnet discussion [mailto:[EMAIL PROTECTED]] On Behalf Of Blake Ryan Sent: Monday, May 13, 2002 7:20 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] DateTime, C# and null 3 solutions come to mind: (a) use DateTime.MinValue to represent null (b) box the DateTime value (i.e. pass it as an object) (c) write a NullableDateTime class The 3rd is the only really "proper" way to do it, as it doesn't assume anything about the DateTime value (as (a) does) or prevent static type checking (as (b) does). I'd suggest a class like the following: class NullableDateTime { public NullableDateTime( DateTime value ); // Throws if object is not null or DateTime public NullableDateTime( object value ); public static implicit operator NullableDateTime( DateTime value ); public static NullableDateTime Null { get; } public bool isNull { get; } // Throws InvalidOperationException if null public DateTime Value { get; } // Returns null if null public object ObjValue { get; } // Returns DBNull.Value if null public object DbValue { get; } } One advantage of this is that the implicit conversion operator allows you to pass a DateTime without explicit casting/conversion. You could argue that the Value property could be implemented as an explicit cast (i.e. public static explicit operator DateTime( NullableDateTime value )), but throwing an InvalidOperation exception from a "cast" operation is not really desirable. Hope this helps. Cheers, Blake > -----Original Message----- > From: Yves Reynhout [mailto:[EMAIL PROTECTED]] > Sent: 13 May 2002 11:03 > To: [EMAIL PROTECTED] > Subject: [DOTNET] DateTime, C# and null > > > Hi, > > what if I had a webservice method which takes a DateTime parameter and > I want to be able to NOT specify this parameter (i.e. pass null > as a value). > One might suggest to use overloading (and run in to the > trouble of having > to give each webservice method a unique name(in the wsdl), > but let's not > delve into that one), but frankly that's not what I want. > > The same question arises (how do I properly handle null with > valuetypes such as int, datetime, ...) when creating [business] > objects. Am I obligated to revert to a homegrown datetime class, int > class, etc... just > to be able to handle the null situation? What is common > practice? How can > this problem be tackled in an OO-minded fashion? > > Awaiting your responses... > > You can read messages from the DOTNET archive, unsubscribe from > DOTNET, or subscribe to other DevelopMentor lists at > http://discuss.develop.com. > KSS Ltd A division of Knowledge Support Systems Group plc Seventh Floor St James's Buildings 79 Oxford Street Manchester M1 6SS England Company Registration Number 2800886 (Limited) 3449594 (plc) Tel: +44 (0) 161 228 0040 Fax: +44 (0) 161 236 6305 mailto:[EMAIL PROTECTED] http://www.kssg.com The information in this Internet email is confidential and may be legally privileged. It is intended solely for the addressee(s). Access to this Internet email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Internet email are subject to the terms and conditions expressed in the governing engagement letter or contract. This email message and any attached files have been scanned for the presence of computer viruses. However you are advised that you open any attachments at your own risk. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
