MVVM and local time versus UTC

We have a rule that all code that deals with datetime does so in UTC.  So when code retrieves a datetime value from a UI it is converted from local time to UTC.  Likewise when code puts a datetime value to a UI it is converted from UTC to local time.  This is pre-MVVM.  Now I'm rethinking the architecture and viewing it in MVVM.

Given that the UI is bound to backing viewmodel properties it seems that the properties on the viewmodel would be in local time.  This isn't great as it adds gray area into the rule that all code is UTC.  However, the separation of the UI may trump that.  Let's say it does.

So all code is UTC except viewmodel properties bound to a UI.  I see quite a bit of sample MVVM code that uses the same properties for other viewmodel work.  If this were the case the local time now leaks further into code.

What am I missing here?  Is it possible for the viewmodel properties bound to the UI to be UTC?  If not, should viewmodel properties of this nature be built in pairs (i.e. a local version bound to the UI and a UTC version used internally by the rest of the viewmodel code)?

What technology? MVC, Silverlight, Win8, WP7?

I'm no expert on MVVM, but to my thinking it should be done in the viewmodel.  The view should only be handling presentation, so that I can swap out the view without changing the behavior of the content.  The view should provide a means of setting a viewmodel property for what zone (format) I want the time in, and the viewmodel should then return the time property in that form.  However, that does not mean that any other code should use the presentation property.  Internal code should be operating on the UTC form, for the obvious reasons, letting the viewmodel maintain the translated version for the view. That particular case doesn't seem like it should be very difficult to implement (certainly some things are difficult to implement cleanly for a variety of reasons).

Of course, that is speaking generally.  Specifics of whatever technology you are using may influence your decision.

@Harlequin: The thoughts are not stack specific per-se.  WPF would be my comfort zone but the goal isn't WPF specific.  If the powers-that-be came to me tomorrow and said make functionality x, y, and z work on iPad then I'd look to xcode for UI and keep the viewmodel and back as .NET as possible (probably via mono*).  MVVM is being considered as a means to minimize the disparate UI stacks from fragmenting the overall system.  By the same token the powers might come tomorrow and say make functionality x, y, and z work via html.  MVC?  I dunno.  Maybe coerching MVVM into MVC is swimming against the current.  I'm open as long as the UI is dangling away from the core code as the goal.

You could retain UTC in the ViewModel by using a Converter in the Binding on the View. I'm not convinced this is necessarily the correct thing to do... but then I'm not convinced local time is always appropriate in the UI, either. Time is always a very trickly little concept that seems so simple on the surface, but confuses you constantly even without digging into the details. For example, we display information obtained from various servers. If we display this info in local time, the user has to make mental adjustments to the timezone in which the server resides... and they may not even know that info. Display it in server local time and you have the reverse problem. Display it in UTC and you have both problems.

Anyway, I digressed. Wanting to remain in UTC in code is understandable, and regardless of how you chose to display it, you can do so while keeping the ViewModel code in UTC by using an IValueConverter in the View.

@wkempf: Of course.  System.Windows.Data.IValueConverter.  And the implementation would be with the View.  So in an "other" (xcode, etc.) scenario a shim mimicking the conversion would be put in place.

@davewill: The nice thing about MVC (I assume you mean ASP.NET MVC) is that it doesn't really care where the data comes from, as long as it originates in the controller. You could hook up your controllers to treat the view models as the model and it would all work fine.

The problem with displaying local time over a web application is that you can't always tell where the user is coming from. In one product I worked on, we associated the default time zone with each user's account. If they moved time zones then it wouldn't be correct, and after agonizing over the problem we decided that it was a non-issue for our use case and stuck with assigning a default.

In my experience, the more calculations based on the time that you need to do, the further towards the view you want to push the conversion from UTC to local. In some cases, it's the last thing done before .ToString(). In other cases, you can do it as soon as it's extracted from the database. Although, I would still recommend putting off the conversion as long as possible so that future changes don't accidently break anything.

What version of the Framework are you using? 3.5 added some timezone related functionality that makes true time zone independance possible, whereas previously it required some nasty kludges.

Here is an example that uses a custom data binding converter :

Implementing the Model-View-ViewModel Pattern in a Windows Phone Application

http://msdn.microsoft.com/en-us/library/gg521153(v=VS.92).aspx">http://msdn.microsoft.com/en-us/library/gg521153(v=VS.92).aspx

@kettch: I too agree that the datetime data and all the handling of that datetime data should be in a single thing, even the UI in a perfect world. But that harkens back to the pipe dream of everyone speaking a common language. It isn't going to happen in my lifetime.

Yes localization should happen at the boundry with the user as really that is its purpose.

I'm glad you mentioned the problem with web applications and not knowing a user's time zone.  Earlier today I quickly had the thought of plumbing the IValueConverter in javascript if demands were made for an HTML UI.  Excellent point. Maybe I should do some thinking on if time zone should be determined or if it should be user provided in all cases. Something to ponder.

We are currently using 3.5.1.  We would love to use 4.5 but there are complexities with some 3rd party dependencies that aren't 4.5 capable. The datetimeoffset from the DB all the way to the UI would be great from what I've read (although in practice I'm not sure how much better than UTC it would be). Unfortunately we have to support back to SQL Server 2005.  2008 was the first version to include that datatype.

@Proton2: Now that is nice to see.  Quite often MVVM reading is done outside MSDN docs.  Nice.

I have been studying mvvm a lot lately and am using it in my first windows phone app that I am developing. I do test driven development completely and wholly for this project.

Some resources I am studying:

The Model-View-Presenter-ViewModel Design Pattern for WPF

http://msdn.microsoft.com/en-us/magazine/hh580734.aspx

Prism: read the article above for more information / links.

@DaveWill2: You should be fine with 3.5.1. I seem to remember that it had everything that we needed. I believe one of the timezone classes TimeZoneInfo(?) has the ability to serialize it's data to a simple string that can then be reimported into the object. Before we got SQL2008 we were using that method to persist the timezone information.