tags:

views:

478

answers:

9

Ok - a bit of a mouthful. So the problem I have is this - I need to store a Date for expiry where only the date part is required and I don't want any timezone conversion. So for example if I have an expiry set to "08 March 2008" I want that value to be returned to any client - no matter what their timezone is. The problem with remoting it as a DateTime is that it gets stored/sent as "08 March 2008 00:00", which means for clients connecting from any timezone West of me it gets converted and therefore flipped to "07 March 2008" Any suggestions for cleanly handling this scenario ? Obviously sending it as a string would work. anything else ? thanks, Ian

A: 

You can send it as UTC Time

dateTime1.ToUniversalTime()

Yitzchok
nope sorry - see previous responses.
Ian
A: 

I think sending as a timestamp string would be the quickest / easiest way although you could look at forcing a locale to stop the time conversion from occuring.

A: 

ToUniversalTime() won't work. ie server time gets converted to UTC, then the client gets it off the wire and converts from UTC to client-local. Same problem.

Ian
A: 

You could create a struct Date that provides access to the details you want/need, like:

public struct Date
{
    public int Month; //or string instead of int
    public int Day;
    public int Year;
}

This is lightweight, flexible and gives you full control.

Timothy Carter
A: 

Why don't you send it as a string then convert it back to a date type as needed? This way it will not be converted over different timezones. Keep it simple.

Edit: I like the Struct idea, allows for good functionality.

Brettski
A: 

yshuditelu - yep - thinking of going with something like this. Adding a custom Date only type to the wire protocol. Its kinda weird that .Net doesn't have one built in - since many Sql implementations support Date only types. Java also doesn't have one - in fact - in my opinion the java date class is hideously over-engineered - but thats another topic.

Ian
A: 

The easiest way I've handled this on apps in the past is to just store the date as a string in yyyy-mm-dd format. It's unambigious and doesn't get automatically translated by anything.

Yes, it's a pain...

Jonathan
+1  A: 

I'm not sure what remoting technology you're referring to, but this is a real problem with WCF, which only currently supports serializing DateTime as xs:DateTime, inappropriate for a date-only value where you are not interested in timezones.

.NET 3.5 introduces the new DateTimeOffset type, which is good for transferring a DateTime between timezones, but doesn't help with the date-only scenario.

Ideally WCF needs to optionally support xs:Date for serializing dates as requested here:

http://connect.microsoft.com/wcf/feedback/ViewFeedback.aspx?FeedbackID=349215

Joe
+1  A: 

I do it like this: Whenever I have a date in memory or stored in a file it is always in a DateTime in UTC. When I show the date to the user it is always a string. When I convert between the string and the DateTime I also do the time zone conversion.

This way I never have to deal with time zones in my logic, only in the presentation.

Hallgrim