SmartDate and Time Zone Offsets

dagware posted on Tuesday, August 07, 2007

How do people handle showing fields like UpdateDate, in the current user's time zone? I don't really care if it's perfect. I know there's a lot of situations that can make this difficult. But I'm only dealing with people on the East and West coast of the U.S., so there's really no need to handle all the potential difficulties. And I don't care if the wrong value is displayed during the few hours when one coast changes to/from Daylight Saving Time and the other hasn't. I just want to handle the most common situation.

So, I'm thinking of storing for each user the number of minutes difference between their time zone and the database's time zone, then having the UpdateDate's getter use the offset to display the value to the user.

Does this sound reasonable? Anyone got a better way?

Dan

dagware replied on Tuesday, August 07, 2007

Just to be clear, the code would look something like this, but obviously not using hard-coded values:

        public string LastUpdateDatetime
        {
            get
            {
                CanReadProperty("LastUpdateDatetime", true);
                SmartDate dt = _lastUpdateDatetime;
                dt.Date = dt.Subtract(TimeSpan.FromMinutes(180));
                return dt.Text;
            }
        }

The reason I'm setting the local variable to the field is so if there's a FormatString specified, it gets used.

It seems there's a cleaner way to do this, but I can't figure it out.

-Dan

RockfordLhotka replied on Tuesday, August 07, 2007

Brad Abrams (.NET framework architect) wrote a blog post about this a while back, you might search for his post to see if it can help.

The problem is a hard one, because the TZ functionality of Windows isn't exposed through a public API. But his blog post talked about some ways to translate dates between local and UNC values in the context of web services and XML. I would think those concepts should translate to broader .NET code.

Patrick.Roeper replied on Wednesday, August 08, 2007

We do the same thing that Andy just mentioned... keep everything in the database in UTC and do the conversion in the getter/setter of the business object property.

public DateTime StartDateTime{

get { return _StartDateTime.Date; }

set { _StartDateTime = new SmartDate(value); }

}

public string StartDateTimeString {

get { return _StartDateTime.Date.ToLocalTime().ToString(); }

set { StartDateTime = new SmartDate(value).Date.ToUniversalTime(); }

}

I just tried to select the relevant bits out for you so sorry in advance for compile errors Smile [:)]

dagware replied on Friday, August 10, 2007

Thanks for the replies (and sorry I haven't replied sooner, I've been sick). I can't really use ToLocalTime, because it's running on a web server, and that won't help. At least I don't think so -- unless there's a web version that converts to the user's time zone, which I doubt.

Rocky - I'll go search that blog. But I've looked into doing this the "correct" way before, and it is REALLY hard. The problem (as I'm sure you know) is that not every place has the same Daylight Saving Time rules. In fact there's one state, I think it's Indiana but I could be wrong, that depending on the time of the year can have three different time zones, or one! That's why I just want a simple method that will work most of the time.

Dan

tmg4340 replied on Sunday, August 12, 2007

If the code isn't going to run on a machine actually in the timezone you need, then you're in a bind. Your web server doesn't know anything about what timezone its requester is in. So you're pretty much forced to have your web clients provide the timezone they are in. Setting aside the issue of how some states decided to handle DST, this isn't necessarily as bad as you might think, especially if you're only aiming for the 80% part of the 80/20 solution.

The typical way that's done via a web app is to associate a timezone to a user ID (assuming your users have to log into your website to use it.) How you store the timezone information is up to you, but at a minimum you would need the timezone name. You would also store all your dates as UTC in the database. You can then work with the TimeZone classes to get the right one for the timezone of the user session and use the "ToLocalTime" method of the TimeZone object to get the right time.

Alas, there is one catch... versions of .NET prior to 3.0 don't allow direct enumeration of timezones - all you can get is the one for the timezone the machine is in - and you kinda need that in order to get the right TimeZone class. Smile [:)] If you are working in .NET 3.0, look at the "TimeZoneInfo" class - there are static methods to get all timezones, as well as to get a timezone by an ID. If you're working in a prior version, then I'd head out to this article:

http://www.codeproject.com/dotnet/WorldClock.asp

Which does essentially the same thing Microsoft waited until version 3.0 to do for you. And it's usually best not to ask why they didn't do it before...

HTH
Scott

dagware replied on Sunday, August 12, 2007

Thanks for the post. I will actually look at the article, because it sounds interesting. But I'm not going to support a bunch of timezones. It's overkill for my purposes. My app is an intranet business app, and users do indeed have to log in, so I'll just keep a user-specified preference for how many minutes difference they are from the East Coast database server.

-Dan