Comments on: Automagic Time Localization

By: Simplify IUserType Testing « Random Code

Simplify IUserType Testing « Random Code — Fri, 16 Oct 2009 02:08:20 +0000

[...] the timezone is relatively simple, I use a slightly modified version of this technique used by Nate Kohari’s most excellent [...]

By: Reflective Perspective - Chris Alcock » The Morning Brew #374

Reflective Perspective - Chris Alcock » The Morning Brew #374 — Tue, 23 Jun 2009 06:53:05 +0000

[...] Automagic Time Localization – Nate Kohari discusses one of the trickier aspects of developing hosted applications for users spread over the world, getting the time right where your user is. [...]

By: Weekly Web Nuggets #69 : Code Monkey Labs

Weekly Web Nuggets #69 : Code Monkey Labs — Tue, 23 Jun 2009 04:28:55 +0000

[...] Automagic Time Localization: Nate Kohari shows a dead-simple way to get users’ time zone…without making them pick from a list of every time zone on the planet! [...]

By: Steve Wright

Steve Wright — Fri, 19 Jun 2009 02:43:06 +0000

@JP: I utilize the .NET 3.5 TimeZoneInfo class to convert times on my websites, I think it only works on Full Trust though, not 100% sure.

By: JP

JP — Wed, 17 Jun 2009 17:22:40 +0000

Of course, the code that I’ve posted works for fat clients, not web clients…

By: JP

JP — Wed, 17 Jun 2009 17:15:41 +0000

.NET 3.5 introduces the TimeZoneInfo class that provides a much better way to convert a time between timezones.

Using it, you can do something like this:
public static DateTime GetLocalTime(DateTime utc)
{
return TimeZoneInfo.ConvertTime(utc, TimeZoneInfo.Local);
}

I’m not sure if it handles daylight saving correctly, but I bet it does.

By: Garry Shutler

Garry Shutler — Tue, 16 Jun 2009 16:22:59 +0000

A step further would be to have all dates sent to the client in UTC and then use Javascript to format them as local time.

This doesn’t require the user to login to update the offset and will work instantly.

By: Chad Myers

Chad Myers — Mon, 15 Jun 2009 23:50:36 +0000

Amen to storing only UTC. Nice trick with the client side discovery. Definitely going to use that one.

Side note, this is known as the “Money pattern”. Any time you have relative values depending on geographic or environmental factors or other variable unit sizes, always normalize to a common denominator. Physical measurements (metric vs English units), Money (currency exchange rates, etc), and time/timezones are good examples.

By: G. Andrew Duthie

G. Andrew Duthie — Mon, 15 Jun 2009 17:03:37 +0000

Fair enough…I think in the case of Zen and distributed teams, your solution may make more sense than mine.

I do wish that working with time was easier in general. Daylight savings time rules in particular are complex, and change often. I long for a simple solution that doesn’t make my head hurt.

By: Steve Wright

Steve Wright — Mon, 15 Jun 2009 16:47:17 +0000

I understand the ease of use of not storing time zone. With this application, I wouldn’t care if times were displaying differently across the daylight savings boundaries because all times would have to change with it based on your current offset.

I disagree that it’s always better to display the localized time because you might be traveling and want to see it in your home time zone.