2

I'm working on an ASP.NET/C# application, which supports time zones.

First let me explain the flow of the application, I'm storing an object for purchase order. So it has the datetime field in it.

I'm storing that datetime as UTC in Database, and binding it in grid (according to the client's timezone).

In the Page_Init method of the first page, I had used a javascript code which will detect the client's timezone, and return appropriate offset.

In the Page_Load method, I'm getting that javascript return value (offset) and comparing it with the offset of each zone in TimeZoneInfo.GetSystemTimeZones().

When comparing the offset, I'm getting a TimeZoneInfo object (for example) "(UTC-08:00) Baja California", "(UTC +05:30) Chennai,Kolkata"

Using that particular TimeZoneInfo object, I'm converting the UTC datetime (which is stored in DB) to the client's timezone.

As by the above flow, the application works fine for some timezones.

The problem is, if when I change timezone of client machine to (UTC -8:00), the client machine shows the timezone name as "(UTC-08:00) Pacific Time (US & Canada)" but in application the timezone differs from the client system it shows as "(UTC-08:00) Baja California".

And importantly DST changes are not reflecting when I convert the UTC to Local. TimeZoneInfo.ConvertTimeFromUtc(DateTime, clientTimezone);

Note: I'm not storing Timezone information of client in database or anywhere. So everytime if a user enters the application, the application will recognize the timezone and it will react according to it.

My question is:

  • Whether the TimeZoneInfo class can work automatically work according to the adjusment rule, when we convert from UTC to Local?

  • Do we have to detect the DST for particular datetime using the method TimeZoneInfoObject.IsDaylightSavingTime(DateTime) and do conversion?

  • Is there any other classes in .Net which can sync with windows timezones?

Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575
Mark ben
  • 105
  • 1
  • 8
  • Basically, obtaining the current offset from UTC isn't sufficient to determine the time zone. See http://stackoverflow.com/questions/6939685/get-client-time-zone-from-browser and similar questions. Your title claims that TimeZoneInfo isn't working, and I see no indication of that in the question - it seems to me that you just haven't got the right time zone. – Jon Skeet Jul 24 '15 at 11:39
  • 1
    (I've reformatted your question to be a *lot* easier to read, by the way. Sprinkling bold everywhere really doesn't help readability.) – Jon Skeet Jul 24 '15 at 11:43
  • Side-note: do you really need the client-local time in the .NET code? If you always provide UTC values to Javascript, that can convert to local time instead, so you don't actually need to detect the time zone. – Jon Skeet Jul 24 '15 at 11:43
  • JS can convert it to local, i'm using pickers for entering the datetime, so i want to set the pickers to client current time, and after client's submit click. I want to pass it DB as UTC. so how can i do that? @JonSkeet – Mark ben Jul 24 '15 at 11:50
  • Why not convert it back to UTC in the client? Basically do *all* local-time work in the client, and make *all* the server-side code use UTC. If you can, of course. If that doesn't work out, see the other question I mentioned for Javascript time zone detection. Most scripts will give you an IANA time zone ID - you could map that to a Windows time zone ID, or just use my [Noda Time](http://nodatime.org) project for all your date/time work instead. – Jon Skeet Jul 24 '15 at 11:51
  • And i saw that above links for getting timezone information of a client's browser. What i need is comparison of that timezone(using that javascript returned offsets) with windows system – Mark ben Jul 24 '15 at 11:52
  • 2
    Please read my previous comment carefully - it explains what you should be getting from a time zone detection system (not just offsets) and what to do with it. – Jon Skeet Jul 24 '15 at 11:55
  • It is not clear for me, if the client system always shows datetimes in its local time (because converting the stored UTC to the actual client's) then why do you display the the "Baja California" and the offset? If I were the client user it would be redundant and disturbing for me. I would expect only the datetime if it is always in my timezone. Missed I something? – g.pickardou Jul 24 '15 at 12:17
  • Converting the stored UTC to client's requires the `timezone` of the client. I got the timezone by using javascript. @g.pickardou – Mark ben Jul 25 '15 at 06:32

1 Answers1

4

A few things you should understand:

  1. A time zone is not the same as a time zone offset. One cannot just take the number -8 and assume that the time zone should be Pacific time.

  2. Offsets can change within a single time zone. For example, Pacific Time usually uses -8, but switches to -7 when daylight saving time is in effect.

  3. The offsets in the DisplayName property of a TimeZoneInfo are only the standard offset. They match with the BaseOffset property. They do not change to reflect the current offset.

  4. Time zone detection in JavaScript is imperfect. There are only three approaches:

    • Using the getTimezoneOffset function of the Date class, which should return you the offset of the date it was called on. For example new Date().getTimezoneOffset() gives you the current offset. With this approach, you should also be aware that there is a bug in the ES5 spec that can cause the wrong offset to sometimes be returned when called on older dates.

    • Using a library such as jsTimezoneDetect, which makes several calls to the getTimezoneOffset to attempt to guess at an IANA time zone identifier. The guess is suitable to set a default time zone when a list of time zones is presented to the user. It is just a guess, and could be wrong. If you want to use it on the back end with .NET, you'll need Noda Time, since TimeZoneInfo doesn't currently support IANA time zones. (You can optionally convert to Windows time zones if desired).

    • Some newer browsers support the ECMAScript Internationalization API, which has an optionally implemented function to return the time zone. It may work in some browsers, but is not guaranteed to return a valid result everywhere.

      Intl.DateTimeFormat().resolvedOptions().timeZone

      Again, you'll need Noda Time on the back end.

  5. You said:

    The problem is, if when I change timezone of client machine to (UTC -8:00), the client machine shows the timezone name as "(UTC-08:00) Pacific Time (US & Canada)" but in application the timezone differs from the client system it shows as "(UTC-08:00) Baja California".

    This is probably related to how you are choosing a time zone in your application code. It sounds to me like you're scanning the list of server time zones and choosing the first one that matches some criteria. Since both of these time zones have the same base offset, you're probably just picking the wrong one, and you shouldn't be doing that anyway. But since you didn't show that part of your code, I can't help you much there.

To answer your specific questions:

  • Whether the TimeZoneInfo class can work automatically work according to the adjusment rule, when we convert from UTC to Local?

    Yes, it can. There's nothing wrong with TimeZoneInfo, it's all about how you're using it. You probably are selecting the wrong time zone.

  • Do we have to detect the DST for particular datetime using the method TimeZoneInfoObject.IsDaylightSavingTime(DateTime) and do conversion?

    No, you should not have to do that just to convert from UTC to a specific time zone. The ConvertTimeFromUtc function will handle that for you.

  • Is there any other classes in .Net which can sync with windows timezones?

    TimeZoneInfo is the only one built in to the .NET Framework. Noda Time is a great alternative that can work with either Windows time zone or IANA time zones.

Lastly, I'll re-iterate what Jon said in comments. If all you're doing is displaying a particular instant in time to an end-user, then forget about time zone detection or working with local time on the server at all. Just send the UTC time to the client, and use either the UTC functions on the JavaScript Date object, or use a library like moment.js. Either can work in both UTC and local, and can convert between them. For example (using moment.js):

var valueFromServer = "2015-07-26T12:00:00Z";     // the Z means UTC
var localTime = moment(valueFromServer).format(); // "2015-07-26T05:00:00-07:00"  (Pacific)
Community
  • 1
  • 1
Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575