locked
best practice timezone RRS feed

  • Question

  • Hi,


    Our servers are in the us, but users in france. If they enter a date with their setting timezone set to france, it will remove six hours, for us and take the date before, as it saves it I GUESS as it was midnight... any idea what should I do?

    Thanks

    Thursday, November 4, 2010 2:10 PM

Answers

  • I brought your question up to a number of MVPs and some Microsoft people, and while they said they were working on something, it appears there is nothing to help out at this time.  The general recommendation was to override the "Time" component to 10:59AM GMT.  But, that only works for concerns relating to the appearance of the "Date" value--as your situation appears to be--for all but 3 timezones in the whole world.  However, I'm assured that those timezones, GMT-12, GMT-11, and GMT+14 respectively, are relatively unpopulated.

    Dave Berry - MVP Dynamics CRM - http:\\crmentropy.blogspot.com
    Friday, November 5, 2010 5:51 PM
    Moderator
  • This is a nasty issue, that I hope MSFT fixes in v 2011.  For instance People's Birthdates shouldn't change just because they are viewed by someone in a different timezone! 

    I think you need to use one of these; I use the first one.  The only trouble I've had is with duplicate detection on update of the records; if one of the fields you are runnning the plugin on is populated.

    http://mhdateplugin.codeplex.com/
    or this http://www.patrickverbeeten.com/pages/ContentItemPage.aspx?id=12&item=86&p=true

    Saturday, November 6, 2010 11:20 AM

All replies

  • I have a similar quandry when it comes to Contracts.  We have sales agents all over the US, and when it comes to Contract Start and End dates, those that are put in on the Eastern seaboard appear to be a day behind on the Western seaboard.  This doesn't even take into account the "local" timezone for the Customer.  In order to reduce confusion, we "normalized" the timezones for sales users to our HQ timezone (but obviously that puts their appointments out of sync; this, however, was seen as a lesser concern), and displayed the "time" portion of the attribute, because our HQ is Mountain, the Pacific timezone occupants still see the previous day in the "date" portion.

    My intent to address this problem, which I have not yet developed, was to put a custom Picklist on the records that I wanted "normalized" to a specific timezone, and inherit (wherever possible) the appropriate value for that Picklist from, say, an Account's location.  Then, with a Plugin operating in the background, I would overwrite the DateTime's timezone (as submitted by the User), into the timezone selected--so that the data would be written in UTC format to the database appropriately.  Then, with a script on the Contract form, I would normalize the displayed value to the selected timezone as well.

    The idea is that the Contract always would show the DateTime value as "local" to the Contract record, and not the user who is accessing the data.  However, since there are certain situations when I would want the user to understand what that time means to their "localized" timezone, the data could be viewed in ways for which the automatic interpretation by the platform would be appropriate (FilteredView queries, Advanced Find, grids, etc.).

    As I said, however, I haven't yet approached this project--and I'm unfamiliar with any other project that performs similarly.


    Dave Berry - MVP Dynamics CRM - http:\\crmentropy.blogspot.com
    Thursday, November 4, 2010 7:04 PM
    Moderator
  • Hi, thanks for your big answer.

    Thanks a lot, There is nothing else simplier to manage this ???

    Friday, November 5, 2010 2:08 PM
  • I brought your question up to a number of MVPs and some Microsoft people, and while they said they were working on something, it appears there is nothing to help out at this time.  The general recommendation was to override the "Time" component to 10:59AM GMT.  But, that only works for concerns relating to the appearance of the "Date" value--as your situation appears to be--for all but 3 timezones in the whole world.  However, I'm assured that those timezones, GMT-12, GMT-11, and GMT+14 respectively, are relatively unpopulated.

    Dave Berry - MVP Dynamics CRM - http:\\crmentropy.blogspot.com
    Friday, November 5, 2010 5:51 PM
    Moderator
  • This is a nasty issue, that I hope MSFT fixes in v 2011.  For instance People's Birthdates shouldn't change just because they are viewed by someone in a different timezone! 

    I think you need to use one of these; I use the first one.  The only trouble I've had is with duplicate detection on update of the records; if one of the fields you are runnning the plugin on is populated.

    http://mhdateplugin.codeplex.com/
    or this http://www.patrickverbeeten.com/pages/ContentItemPage.aspx?id=12&item=86&p=true

    Saturday, November 6, 2010 11:20 AM
  • Unfortunately, there is no indication that this will be "fixed" in vanilla CRM 2011 at release.  It would be nice to see a patch, after the fact, but I'm also holding out for a way to localize a specific record, rather than assume that records are always local to the user interfacing with them.

    Dave Berry - MVP Dynamics CRM - http:\\crmentropy.blogspot.com
    • Proposed as answer by NateOne Monday, November 8, 2010 8:50 AM
    Monday, November 8, 2010 1:40 AM
    Moderator
  • Dave, yes that would be one way to fix the problem.   Until then I guess we'll have to use those plugins, so I proposed both of our posts as answers.
    Monday, November 8, 2010 8:51 AM