Windows/C# Detecting user's hemisphere via OS (not IP address)?

Refresh

March 2019

Views

252 time

1

I've got an C# .Net (4.0) application for which I'd like to do some logic based on the season. This application will be used by people in both the Northern and Southern hemispheres, and may or may not be on a machine that's connected to the Internet.

Another SO user has asked a similar question here, which let me to pursue a solution based on the machine's local timezone info. My "port" of the JavaScript to C# looks roughly like this:

        TimeZoneInfo tzi = TimeZoneInfo.Local;

        TimeSpan january = tzi.GetUtcOffset(new DateTime(System.DateTime.Now.Year, 1, 1));
        TimeSpan july = tzi.GetUtcOffset(new DateTime(System.DateTime.Now.Year, 7, 1));

        TimeSpan diff = january - july;

        if (diff.TotalDays > 0)
        {
            Console.WriteLine(tzi.DisplayName + " is in the Southern hemisphere");
        }
        else
        {
            Console.WriteLine(tzi.DisplayName + " is in the Northern hemisphere");
        }

My machine's timezone happens to be in the Northern hemisphere, and correctly outputs:

(UTC-06:00) Central Time (US & Canada) is in the Northern hemisphere

If I swap out the line:

TimeZoneInfo tzi = TimeZoneInfo.Local;

with a timezone I know to be in the Southern hemisphere, it also looks promising:

TimeZoneInfo tzi = TimeZoneInfo.FindSystemTimeZoneById("Cen. Australia Standard Time");

outputs:

(UTC+09:30) Adelaide is in the Southern hemisphere

So far so good. But this trick only works if the timezoneinfo observes daylight savings time. Which leads to:

> (UTC+09:30) Adelaide is in the Southern hemisphere
> (UTC+09:30) Darwin is in the Northern hemisphere
> (UTC+10:00) Brisbane is in the Northern hemisphere
> (UTC+10:00) Canberra, Melbourne, Sydney is in the Southern hemisphere

I suppose I could brute force a static dictionary of timezoneinfo/string and hard code them all, but I was hoping there was a more elegant way.

1 answers

2

A good approach might be to use geolocation if available. This will get you a good result for users who are connected to the internet. For users that aren't connected to the internet, your time zone solution would work well. Unfortunately I think you will have to make a static dictionary to handle the timezones that don't use daylight savings time.

Timezones are sometimes set for arbitrary political reasons, which makes it hard to use them for this sort of thing in a completely uniform way.