In .NET, the DateTime structure provides us wonderful functionality, but this seemingly simple structure can cause a lot of headaches if you don’t fully understand how to use it properly.

Understand the terminology

First, UTC, GMT, and even Zulu time are all the same thing. They’re basically a universal time clock that is not subject to changes in time zones or time changes. Each tick of the universal clock represents a moment in our perception of time.

Use UTC as long as possible

UTC is very useful when developing software because it removes the need to know where the time was from, or where it’s going to be used. We don’t even care when it was from, or when we’re displaying it. You can think of your local clock as a view of the time right now, where you are. It has already taken into account the time zone and daylight savings time.

These properties of your local clock suggest that we should always convert from the local clock to universal time as early as possible when accepting user input, and convert it back to the users time only when displaying it. This is a simple, easy to use pattern that may be enough to avoid some of the potential problems that other projects face. This pattern will give you the ability to cope with time changes and time zones much more easily.

Converting between local time and UTC is pretty easy. ToLocalTime will convert from universal time to local time. ToUniversalTime will convert to UTC. Just be aware that these methods have a certain amount of logic in them that only has the rules that were in effect when they were written. They are not perfect for all scenarios. You’ll also want to take a look at the Kind property, which affects which conversions you can perform, as well as providing a nice way to keep track of whether or not he time has been adjusted to UTC.

Daylight Savings Time & Time Changes

Every year in many parts of the world, the time changes. Apparently the idea is to save gobs of money by using the sunlight more efficiently instead of using artificial lights. Unfortunately, this really sucks for software developers.

I used to write software for manufacturing facilities that would run during a time change. If you have software that records and time-sensitive data during a time change, your software had better be prepared to handle it the fact that one hour is skipped, and another is repeated. Storing the data in UTC solves part of the problem. Unfortunately, when you try to display the data you’ll have an hour of missing data, and a hour with overlapping data. You may have to design your user interface to deal with this.

Fixed-time Appointments

Unfortunately, UTC doesn’t solve all of our time offset problems. Let’s say that you have an appointment that you’re scheduling for a future date that occurs when DST is in effect, but it’s not in effect right now. You choose 5:00am for your appointment time. Your application happily converts the time to UTC, and the reverse process expectedly yields the same result. The problem is, the time offset when the appointment occurs will be different than it is now. Daylight savings for the central time zone for example, switches between and offset of –5 and –6. This diagram attempts to visualize:

What we want to store is the fact that our appointment occurs at 5:00am local time. If we simply store the information as UTC, we’re losing this additional information. When we switch to non-DST time and use our current time adjustment of –6 hours, our appointment now occurs at 4:00am.

If you’re writing an application that stores fixed-time appointments as well as appointments that are designed to have even intervals (exactly 1 month apart, etc) or occur in a different time zone or DST, you’ll need to store an additional flag with the event so you can make the determination if it needs to be adjusted.

Conclusion

Times can be complicated depending on the requirements of your project. It would be unwise to work these problems out toward the end of a project, because the consistency of usage can’t be guaranteed. Do yourself a favor and plan ahead for these issues, and it will be much easier.

I’ve been working on a unit testing paper that sums up my experience in unit testing, and discusses some of the core information that I feel is important about the subject. It’s very much a work in progress, but I wanted to get it out sooner rather than later. I’ll be continuously updating it as time goes on.

Update: I updated the PDF location to one that doesn’t require registration.

There are some really great books out there about unit testing, but I think some of them are trying too hard to be long enough to be considered a “book”. I set out to create a document that fills the gap between the various snippets of information from blog posts, and the comprehensive books on the subject. If you’re interested in something a bit more in-depth, here are some great books on the subject:

• The Art of Unit Testing by Roy Osherove
• xUnit Test Patterns by Gerard Meszaros

The paper currently consists of 5 main sections:

• Why Write Unit Tests?
• Unit Test Mechanics
• Common Unit Testing Strategies
• Designing for Testability
• Advanced Techniques

Here is a more complete snapshot of the current outline:

• Introduction
• Unit Testing & Managers
• What Unit Tests Really Do
• Types of Testing
• Testing Framework
• Test Runner
• Unit Test Structure
• Other Test Attributes
• What is Refactoring?
• Test Driven Development
• Evolving Code
• When Should You Write Unit Tests?
• Test is for Functionality, Not Code!
• The Constraints of Reality
• Interfaces - Quick Overview
• Using a Mocking Framework
• Stubs
• The Test Driven Design Paradox
• Testing Under Pressure
• Extracting Duplicate Logic
• Modular Design Benefits

So what are you waiting for? Go check it out online instantly, you can even download it as a PDF if you like. Is anything missing? Is anything just plain wrong? I’d love to hear your feedback.

Remember, if you want to hear more about unit testing, I’ll be speaking in Northeast Wisconsin Saturday, May 9th.

If you’re interested in hearing about writing practical unit tests in .NET, I’ll be speaking at the Fox Valley .NET user group “Day of .NET” event May 9th! Here is the synopsis for your reading pleasure:

Want to learn how to write good automated unit tests that are beneficial both to the product/customer and to you as a developer? See an overview of the mechanics of unit testing including the tools and frameworks available. You’ll see examples of how to test existing code, but you’ll also see practical examples of how seemingly un-testable code can be designed so that it can be tested with ease. Learn how test driven development and refactoring will improve the readability of your code, minimize debugging, and speed up development.

If you’re anywhere near the Northeast Wisconsin area, stop in. It’s free!

I’ll be publishing both the presentation and a supporting 25+ page paper shortly, so make sure you’re subscribed to my feed.

Fox Valley Tech is located at:
1825 N. Bluemound
Appleton, WI 54912

Today’s tip comes from the “Anally Retentive” department. In the .NET CLR team likes to keep their lines of code under 110 characters long. I’m assuming that they’re trying to maintain consistency and readability. I often try to maintain an imaginary line length limit, but I doubt I’m very consistent.

Fortunately, Visual Studio provides a hidden feature that lets you draw a vertical line in the text editor to show you where a certain line length would end. Fire up your registry editor and find this key:

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\Text Editor

If you’re using a version of Visual Studio before 2008, you’ll need to decrement the 9.0 version number in the path above.

Then, add the following value (as a string or REG_SZ) with the name of “Guides”:

RGB(192,192,192) 110

The first part is the color, and the second part is the line length. Personally, I use a line length of 110 to stay consistent with how Microsoft has chosen to do it. I like the color listed above because it’s faint, but visible. Since the line is almost impossible to see in the screenshot above, here is an un-scaled screenshot of the line itself:

To further enforce the 110 character limit, you could also resize the code portion of your Visual Studio window so that it’s near the line. This will make the line itself a little less annoying, while allowing you to use the rest of the window for other information. For example, take a look at how much room I have on a 1920×1200 screen when I horizontally resize my code window:

Obviously this tip isn’t for everyone. You may be working with legacy code with long lines, or you might work on a team that doesn’t mind long lines. The great news is that Visual Studio is pretty accommodating to however you like to work.

Joel Spolsky and Jeff Atwood stirred up some debate when they said “Quality just doesn’t matter that much”. At first, I was a little outraged. My entire development process is built around quality. Without it, airplanes would fall from the sky and your car wouldn’t start in the morning.

So can we definitively put the quality question to rest? Unfortunately, “No”.

First of all, we need to understand that quality isn’t a Boolean. It’s not “yes”, you have quality, or “no”, you don’t have quality. Quality is a gradient, but it’s even worse than that. Everyone sees it differently, and everyone experiences a different aspect of it. In short, quality is a multidimensional gradient!

I used to work at a small development company where I worked very closely with the President of that company. He was concerned with quality, but that took a backseat to the features that went into the product. The features themselves sold the product, and wowed the people writing the checks. Once they purchased our software, the integration efforts were large enough that the customer was essentially locked-in. Throw an expensive support contract into the mix, and it was a money making machine.

The company ended up being very successful, and was eventually assimilated by a huge company. The owners ended up walking away with a few million each. Try to explain to them that quality is more important than features!

Now fast-forward a few years, and we can examine what eventually happened. The product did work, and honestly it was the best in its class simply due to the scope of the problems it was trying to solve, and the high barrier of entry for competitors. However, the quality issues eventually caught up with the product. It became difficult to maintain and add extra features. The only solution was to slowly rewrite sections of it.

I think a great analogy is the turtle and the hare. If you’re in for the long haul, you want to be the steady turtle. If you’re in it for the short term, you want to be as quick as possible, even at the cost of stopping to nap. The problem is, you’re making others suffer for your negligence.

If you want the best of both worlds, build quality into your development process. I’ll be covering this in a series of articles that discuss unit testing (and testing in general) in exhaustive detail. They should be coming out by the middle of March. Stay tuned!