Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I am specifying enhancements to a system that will need to report on employee activity in different time zones.

I anticipate that users of the system will be able to set a 'Home' or Local Time Zone - and I think that the reports and UI will be most understandable if the user sees the local time of the event, wherever that event happened.

However, I do not want to obscure the fact that some times pertain to a different time zone. Let's just assume for a moment that I want to display a 09:00 start time for employee A in Athens Greece, employee B in London England, and employee C in New York USA, and I am in New York. This example uses offsets relative to New York

A:  09:00 +07:00
B:  09:00 +05:00
C:  09:00

I believe that this solution would be relatively easy to implement using DateTimeOffset types in Sql Server and .Net, but I am uncomfortable about it because it kind-of looks like a ISO8601 format, but it definitely is not that, as the hour offsets are relative to New York, not relative to UTC.

Perhaps instead of using hours offset we could specify a time zone instead:

A:  09:00 [EET]
B:  09:00 [UTC]
C:  09:00

The concern I have with this solution is that DateTimeOffset and such only store an hour-offset, and do not store this time zone information... and it may be non-trivial to discover which actual time zone the event was in later on (consider Daylight Saving Time changes).

Bear in mind employee A might be in Athens one day, and Berlin the next, and so we can not assume on that being fixed, or decide to exclude 'non-home' data from a report.

While I am most interested in the display format others would suggest for this situation; one caveat is that the solution must be fairly easy to implement and quick to process.

share|improve this question
    
so If i get you right you want to show the meeting time in their current local time? –  Mervin Johnsingh Mar 7 at 14:11
    
@MervinJohnsingh - No - these are not meetings (I see now the ambiguioty of the term 'events'); these are displaying times that things happened. So for example, there might be a 'timesheet' report that displays the time people started their work day at, but each employee might be in a different country. –  Nij Mar 7 at 17:55

2 Answers 2

Mobile apps have the benefit of utilizing geo-location data to exactly determine where the user is at, converting times relative to the time zone they are in.

With websites, most of the time you see options for users to expressly state what their preferred time zone is. The onus falls upon the user to change their time zone if they wish.

You could provide a microinteraction loop that seeks to determine the user's location based on their IP address. If the address is resolving outside of their stated time zone, you could provide a small tooltip stating the potential problem: "It looks like you're not currently in [STATED HOME TIME ZONE]." Then offer a resolution such as, "Change time to [CURRENT TIME ZONE]."

Here's a sample tooltip from Gmail:

Gmail Tooltip

share|improve this answer
    
I want to display times for employees in many different time zones in the same report or screen display; my question is not about how to discover what time zone someone is in. My question then extends to considerations of how complex any implementation will be. –  Nij Mar 7 at 17:58
up vote 1 down vote accepted

In the end the client has chosen to aim for the use of Time Zone abbreviations where they are necessary (i.e. not in the current time zone)

A:  09:00 [EET]
B:  09:00 [UTC]
C:  09:00

While users of this UX forum may not care too much about implementation details, this means we won't be using DateTimeOffset as the underlying type to store international times. We have decided to store local times, with a TimeZoneId which will tell us how many hours from UTC the time was. This will make comparisons of absolute times harder, but will provide what we think will be a good 'natural' way to view time for the majority of interface elements.

share|improve this answer
    
#winces# - Any time you're dealing with a log (a record of events), it should be stored in absolute terms (UTC, essentially). Your current form is probably not safe if DST changes. Display is trickier - depending on use, you need to be able to report in local-to-event or local-to-asker terms. Note that some timezones have non-hour offsets! It sounds like you aren't separating display from storage, which may be a problem in other areas. –  Clockwork-Muse Mar 24 at 6:17
    
Hi @Clockwork-Muse, Do you have a reference for your 'it should be stored in absolute time'? But, even if the general case is that UTC is a good storage format, my client has decided not to take that route - as times between zones will tend not to be compared in this application. I believe that the storage form LocalTime + TimeZoneId protects from time zone changes; e.g. if BST ever changes it will probably get a new acronym! (but we will likely store and identity value to a lookup table anyway); i.e. we will be able to calculate UTC when necessary. –  Nij Mar 25 at 8:51
    
Some of this depends on your database vendor and application language - ie, C# has very poor/strange timezone-switching support (see the relevant discussion in NodaTime). It does matter somewhat less if you never compare them... however, I've worked on a system where (for one application) timestamps were written in local times (and unfortunately without any timezone info) - stuff from the future kept appearing! You do not get a new acronym if when DST occurs changes; when the US changed in 2007, Mexico didn't (initially) follow suit, and there were two separate uses of PST/PDT... –  Clockwork-Muse Mar 25 at 12:24
    
Thanks @Clockwork-Muse. Yes - I have read about Noda Time and but I'll be a little surprised if that is taken up by the client. Your example of the US in 2007 was new to me, but again I am not convinced it matters hugely to this client. Simply recording the 'current' time zone at the time of an event e.g. PST / PDT will still be enough to account for time-offsets later. BUT in some senses I am cheating because I am assuming the continued use of TZ4Net or similar to calculate the current TZ at a time. Thanks again! –  Nij Mar 27 at 5:53

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.