Sith Lord in Training Archives : Global Nerdy

You’d think that with 10,000 years of date- and time-keeping under our belts, it would be easy to keep track of dates and times in a modern-day database. It’s a little trickier than you might think, according to The Death of DateTime?, an article in Bart Duncan’s SQL Weblog.

The gist of the article is pretty simple: if you’re using SQL Server 2008 and want to store dates and times unambiguously, use the datetimeoffset type (introduced in SQL Server 2008) rather than the traditional datetime.

Why? Because datetimeoffset is datetime with these key differences:

The time value is stored internally in an unambiguous UTC format
The local time zone offset is stored along with the UTC time
It is capable of storing more precise times than datetime

Duncan recommends that if you’re storing data in SQL Server 2008, you should almost always store date-and-time values in datetimeoffset rather than datetime. It’s a good idea; I’d go even farther and suggest that if you’re programming using .NET 3.5, you should make use of the corresponding DateTimeOffset type instead of DateTime. You can read more about .NET 3.5’s DateTimeOffset type in this entry in Dan Rigsby’s blog titled DateTime vs. DateTimeOffset in .NET.

When might you want to use datetime? Duncan suggests that you should use it in those rare cases when you want to store time ambiguously. The example he provides is: “if you wanted a column to record the fact that all stores in a chain should open at 8:00am local time (whatever the local time zone may be), you should use datetime.”

Thanks to Brent Ozar for the link!

Round Trip

Back when I was working for OpenCola (from January 2000 through January 2002), the start-up cofounded by Cory Doctorow, I was doing a lot of work using beta versions of C# to build prototype peer-to-peer applications that got demoed to some large companies, including Microsoft, who were kind enough to provide us with betas of Visual Studio .NET and Windows XP.

I graduated to the 1.0 version when it came out. Even during the year after I left OpenCola (or more accurately, got the boot), I continued to write applications in C#, from things like a sales app for people who were selling practice certification tests to a trivia game for a company that was pitching it to Maxim. I do manage to land some interesting jobs from time to time.

That changed on Bastille Day 2003, my first day as Tucows’ Technical Evangelist, or as the title originally read, “Technical Community Development Coordinator”. Tucows’ client base were people who wanted to resell things like domain names and email, and as such were largely hosting companies. This in turn meant that they were using languages that you might consider “webbier”: open source dynamically-typed languages like Perl, PHP, Python and Ruby. I did what I could to stay away from Perl, I’d coded in PHP and Python for work before, and I picked up Ruby along the way.

Feeling a bit restless, I left Tucows in late 2007 to do Ruby on Rails development at what turned out to be Toronto’s worst-run startup, possibly ever. After that, it was project management at b5media, where I used Ruby to implement some “housekeeping” scripts. Although I hit up Microsoft Evangelist David Crow for a copy of Visual Studio so I could try out XNA, I really didn’t pay too much attention to C#. I installed it on my machine, wrote a lazy “Hello, World” app – a single WinForm with a button that displayed a MessageBox with the word “poop” when you clicked it – and promptly forgot about it.

The situation changed when I got laid off in September and then got hired as a Developer Evangelist for “The Empire” in October. Suddenly, I’m back in a world with a three-versions-later Visual Studio and a two-and-a-bit-versions-later of C# and .NET. I’ve got the programming know-how and the language basics down cold; it’s the changes in the language and library – generics, LINQ and a bunch of 2- and 3-letter acronyms beginning with “W” – that keep catching me by surprise.

Luckily, management is cool with my first year being a “learning journey”. They’re really interested in how I mix my schmoozing and community-building skills with a love of technology and programming and don’t mind that my first year is a “learning journey”. They especially don’t mind if I share what I learn along the way, which is what this series of articles, Sith Lord in Training, is all about. As I learn more about C# and the .NET framework, both present versions and the upcoming 4.0 versions, I’ll write about them here.

Default Parameters in C# 4.0

Suppose that you’ve got a method that takes a single boolean argument. Here’s how the argument affects what the method does":

If the argument is anything other than true or if no argument is provided, the method performs its normal task.
If the argument is true, the method performs its task, plus some additional stuff.

Here’s the Ruby implementation:

# Ruby

def myMethod(doSomethingOptional = false)
    puts "Doing my regular thing."
    if doSomethingOptional
        puts "Doing the optional thing."
    end
end

doSomethingOptional is a parameter with a default value. If myMethod is called without any parameters, doSomethingOptional is given the default value of false.

Unfortunately, the current 3.0 version of C# doesn’t support parameter defaults. The way to emulate this behaviour is to use method overloading:

One method to handle cases where no parameter is given
Another method to handle cases where a parameter is given

Here’s the implementation in C# 3.0:

// C# 3.0

public void MyMethod()
{
    MyMethod(false);
}

public void MyMethod(bool doSomethingOptional)
{
   Console.WriteLine("Doing my regular thing.");
   if (doSomethingOptional)
   {
       Console.WriteLine("Doing the optional thing.");
   }
}

That’s a bit long-winded for something that should be pretty simple. Luckily, this has been fixed in C# 4.0:

// C# 4.0

public void MyMethod(bool doSomethingOptional = false)
{
   Console.WriteLine("Doing my regular thing.");
   if (doSomethingOptional)
   {
       Console.WriteLine("Doing the optional thing.");
   }
}

And with that, the long-winded (and unnecessary, at least to my mind) method overloading workaround vanishes. Yay!

Named Parameters in C# 4.0

Named parameters make the meaning of the parameters explicit, as long as the parameter names themselves are pretty meaningful. Contrast the following call:

drawCircle(100, 200, 200, "yellow")

with this, which is supported in Python:

drawCircle(radius = 100, x = 200, y = 200, color = "yellow")

C# 3.0 doesn’t support named parameters, but C# 4.0 does. Here’s how you’d call MyMethod in C# 4.0 using them:

myMethod(doSomethingOptional: true)

As for the Python drawCircle method in the example above. here’s how you’d call it in C# 4.0:

DrawCircle(radius: 100, x: 200, y: 200, color: "yellow")

If this syntax is giving you some deja vu, it might be because it’s reminding you of Objective-C, where the call would look something like this:

[someObject drawCircleWithRadius:100 x:200 y:200 color:"yellow"]

See the Video

If you’d like to see more about default and named parameters in C# 4.0, there’s a video on the Chanel 9 site that covers them quite extensively. Go check it out!