.net - defining TimeZone at application level

Question

I have a global application compsed by many sub-applications :

Web sites
Windows services

I want to dispatch those "application part" in many servers. My problem is : I want the dates to be still accurate. If an event is stored at 6:00 PM pacific time, I don't want my european users to see "6:00 PM" on their board.

I've read a lot of articles that say "you just have to save your dates that way" => but I can't change the way each single date is saved, that represent too much work (and yes, it's datetime that are saved and not dateoffset).

I've read other articles that propose to change the time zone on the server => But I can't want to do that, as those server can be used for others purposes.

The good news is that dates are always defined in the application and not generated by the database.

In consequence, the only thing I have to do is to define the TimeZone at application level. So wherever they are, my applications will always work with the same timezone. The only step left will be to convert the dates at UI level, in the timezone of the current user (very simple as all dates are passing throught the same localized datetime conversion method).

I really cannot afford to changes the ways the application developpers work, as it will be prone-to-error. They need to keep using DateTime.Now, without ever thinking of conversion.

The exact technologies I use are not relevant here, the question is global .Net.

Thanks for your help

Edit : let's say my problem is just to have DateTime.Now return the UTC date. Is there a way to do that ?

Can't you use `app.config`? Is there an actual question here? — bzlm, Jan 21 '11 at 17:40
So what you're saying is, "I don't have time to do things the right way, I just want to get the right answer while keeping the wrong code." Does that sound about accurate? — Jon Skeet, Jan 21 '11 at 17:42
Prone-to-error? Store and retrieve everything as a time in UTC. I think that's your only real solution. — hometoast, Jan 21 '11 at 17:42
Related question: http://stackoverflow.com/questions/2532729/daylight-saving-time-and-timezone-best-practices — Oded, Jan 21 '11 at 17:42
@JonSkeet : hard answer you give me ^^ fact is they are many developpers in many countries working on many parts of a global plateform, and lot of them are freelances that work on the application for a couple of weeks. My problem is to find a solution to that problem, and having DateTime.Now always returning the UTC date is the solution. Another solution is to replace every DateTime.Now in DateTime.UtcNow, reviewing all the code of all the developpers on all the parts of that plateform... well if i can choose... — Mose, Jan 22 '11 at 15:08
@hometoast : having all developpers doing good code is the solution to many problems, but in that particular case I KNOW they are using DateTime.Now everywhere, and if I tell them to se UtcNow, they will do it for 2 weeks, then forget. what is "Prone-to-error" is to do things expecting many developers wokring on the same plateform to do it the same way. — Mose, Jan 22 '11 at 15:14
@Mose: Using the right solution is often slightly more work in the short term, but *much* better in the long term. Do you not already have code review in place? If not, that sounds like you've got bigger problems than time zones. Even if you haven't, it would be easy to automate a source code check. — Jon Skeet, Jan 22 '11 at 16:40
@JonSkeet : as you can define the current culture (for localization purpose), I hoped there was a way to define the current timezone (for application delocalization problems), or globally change the way DateTime.Now reacts. Using DateTime.UtcNow may be the best practice for international applications, but in term of separation of concerns, this is a little annonying because a developer on a small functionnality in a global plateform needs to be aware of that. Thanks all for your help, I think I'll force the system TimeZone on the servers ^^ — Mose, Jan 22 '11 at 17:39
@Mose: Yes, developers need to be aware of what they're doing in all sorts of ways. They almost certainly shouldn't use Encoding.ASCII for a global site either... but if I found someone using Encoding.ASCII, I wouldn't try to change what that meant - I'd fix the code. Fixing the code to work properly is almost always more effective in the long run than applying workarounds. — Jon Skeet, Jan 22 '11 at 18:35
@Jon :yes and no, developers does not need to be aware of everything, that's why WCF what introduced, to separate the concerns between a functionnality and the way it's used. That's why IOC has been introduced, to add loose coupling between component. Why does the .Net framework allows us to set the current culture in a Thread ? For the developer to keep working as normal, the .Net framework will adapt the DateTime.ToString() result adequately. I really feel that not being able to set the TimeZone is... like if this idea was only half done. — Mose, Jan 23 '11 at 01:49
Create a FxCop rule to point out everytime DatTime.Now is being used and throw a warning — Pauli Østerø, Jan 24 '11 at 22:28

hometoast · Accepted Answer · 2011-01-24T22:17:24.360

1

Store all times in UTC.

DateTime.UtcNow

then take care of the TZ correction on the client.

Edit: I missed that crucial part about not changing DateTime.Now. Make the programmers do it right; it's not less prone to error.

You either need to have all client code use DateTime.UtcNow OR have all client code use the database for getting timestamps. Either way -- you've got work to do.

Good luck!

edited Jan 24 '11 at 22:17

answered Jan 21 '11 at 17:40

hometoast

11,522
5
41
58

Asking many programmers, whose teams are changing all the time (and sometime freelance developpers just here for couple of weeks) that use DateTime.Now as it's a .Net standard way to get the date, THAT is prone-to error. We'll need to review the code all the time to correct things on every project. – Mose Jan 22 '11 at 15:21
Well there's only two ways to do it. And both ways involve changing a lot of things. OR forcing all client machines to set UTC timezone (and praying they keep that promise -- if they change it, unless you have code to check it, you'll never know). – hometoast Jan 24 '11 at 22:15

score 0 · Answer 2 · answered Jan 21 '11 at 17:42

0

I'm going to give you a simple answer, with the understanding that if the answer is this simple, I'm probably misunderstanding the question:

Save the timezone of the local application on the server. Then you can transform the local time however you need to. If your local developers are using DateTime.Now, that's fine, as long as somewhere in the database, you're able to say that this value of DateTime.Now is adjusted for this timezone.

Is that it, or am I overlooking something?

answered Jan 21 '11 at 17:42

Chris B. Behrens

6,255
8
45
71

You solution means changing millions of lines of code ^^ As we need to change the way every date is saved. And this is the problem I want to solve... – Mose Jan 22 '11 at 15:16
@Mose: Yes, when you've gone along with a broken way of doing things for a long time, it can take a little while to fix - which is why it's important to *stop* using the broken way of doing things as quickly as you can. – Jon Skeet Jan 22 '11 at 16:41

score 0 · Answer 3 · answered Jan 21 '11 at 17:45

An option: Save All Datetimes at GMT/UTC then get the timezone via javascript from the user (their browser) and display the dates taking into consideration that timezone.

// Gets the Browsers timezone offset in minutes
function getClientTimezoneOffsetInMinutes()
{
    var rightNow = new Date();
    var date1 = new Date(rightNow.getFullYear(), 0, 1, 0, 0, 0, 0);
    var date2 = new Date(rightNow.getFullYear(), 6, 1, 0, 0, 0, 0);
    var temp = date1.toGMTString();
    var date3 = new Date(temp.substring(0, temp.lastIndexOf(" ") - 1));
    var temp = date2.toGMTString();
    var date4 = new Date(temp.substring(0, temp.lastIndexOf(" ") - 1));
    var hoursDiffStdTime = (date1 - date3) / (1000 * 60 * 60);
    var hoursDiffDaylightTime = (date2 - date4) / (1000 * 60 * 60);
    return hoursDiffStdTime;
}

I think you misunderstood : the problem is not at interface level, it' at the application level. Let say I have a windows service in HongKong that creates a log at 6:00PM. An that log will be consumed by another Windows service in France at 6:00PM. What I need to store in my database are UTC dates. Javascript won't help me — Mose, Jan 22 '11 at 15:18
Yes, as mentioned, save all dates at GMT/UTC, javascript will help you get users timezones so you can display dates correctly for them (unless you know this from their profiles etc) — Mark Redman, Jan 22 '11 at 17:08

.net - defining TimeZone at application level

3 Answers3

Linked