October 25, 2009 at 12:16 pm
It looks like we may need to adjust an application to support users from other countries, which means we will need to adjust how we display and record the current date and time.
I'm just curious about how others are doing this, are you storing all your datetime as UTC and then applying the offset in the application's presentation layer?
October 25, 2009 at 9:46 pm
I haven't done a lot of this, but when we had salespeople across the US, we used UTC as a standard. That way we were sure of the timing of sales across different time zones. We had to know who entered an order first in case we needed to back order something. A person entering a sale at 1:20pm EST had precedence over one at 1:15PST.
This also insulates you from issues with different, or incorrect time settings on machines. For example, if a user forgets to reset their time when changing time zones and then enters something.
October 26, 2009 at 6:25 am
So you just asked SQL server for the datetime instead of ever asking the user's local machine, and just recorded that on the record (and used UTC on the record)?
How did you convert that back for the user when they viewed the data?
Did you just use their machine's local settings, or did the user have a profile setting somewhere that indicated their time offset?
October 27, 2009 at 7:58 am
What platform is your app targeted to? Is it Windows? Windows has a rich (if somewhat convoluted) API for dealing with time, and Windows knows about time zones. If you're using the latest version of .NET Framework then it's even better -- .NET (and/or Windows API) makes translating to/from UTC relatively easy. It really becomes a matter of presentation -- always pass date/time around in UTC, and just present it to the user as local date/time using the API/framework in your application. It's easy!
Except when it's not. UTC is really the least of your worries -- in fact I'd say that it's probably relatively trivial. Of bigger concern is different date/time *formats* between locales. US format: MM/DD/YY, French format (I think) DD-MM-YYYY, etc. That'll cause you more headache than UTC vs. local time, I think. Users will want to enter dates/times in their local format, and if you mistranslate *that* then it can cause all sorts of wackiness. Again, if you're using Windows and .NET, it's easier, but not trivial -- Windows/.NET knows about the user's locale and can help you convert local date/time format from and into UTC....but you better be darn sure you've got all the code accounted for and you're getting it right.
Do users need to enter dates/times or will you just be presenting date/time of an event (e.g. when a record is saved)? that'll help you decide whether or not to get date/time from server or from user. Also need to consider how tolerant you are of errors/discrepencies (e.g. one user has wrong locale settings or their clock is off).
Sorry, I don't think that was much help. We struggle with it here too...where we need to we will store dates as UTC and then translate that to user's local settings (or translate from local settings to UTC). It's not terribly hard, but it can be hard to get right.
October 27, 2009 at 8:06 am
We used local settings, which still caused issues. Users would travel, forget to move settings, and call us.
However if someone moved and used another machine locally, they got the correct data.
It's a struggle. Some good points bydmbaker above, about different formats as well.
October 27, 2009 at 10:03 am
Thanks for the replies, it is good to hear that everyone is having the same issues we are running into.
I just wanted to make sure there wasn't some silver bullet where everyone would go "Oh yeah, do this, call that function, and use these three steps, works every time!" 🙂
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply