Well, DateTimeOffset isn't a class to start with - it's a struct. But it's still not the panacea some people seem to think it is. There are plenty of situations where what you want *isn't* a DateTImeOffset. Its inclusion was definitely an *improvement* on the state of the date/time API in .NET (as was TimeZoneInfo, for sure) - but that doesn't mean it brings it up to a decent state, IMO.

"It either works or it doesn't" - or it works for all but one or two hours of the year, around a time zone transition. Or it works so long as you're in a time zone which doesn't skip 00:00 when it transitions forward by an hour. Or it works so long as you're not in time zone which skipped a whole day once. How sure are you that all your code works in all of those conditions? How *clear* is your code in terms of which values are meant to be local, which are meant to be in UTC, and which are meant to be local in some other time zone?

You say that date manipulation in .NET is really not hard - but I've seen an *awful* lot of subtly-broken code using DateTime, and even correct code isn't always *obviously* correct, mainly because `DateTime` doesn't represent one single concept.

I looked at the .NET DateTime functionality *very* hard before deciding to write Noda TIme - and now, 5 years later, I'm still convinced that it was the right thing to do.

Glad you've liked Noda Time - but if you could drop a line to the mailing list or raise an issue for any "Java-isms" you've found, I'd be grateful. I've tried to make it as idiomatic to .NET as I can, other than where doing so would be harmful.

A lot of work on the C# compiler, while he was still working for Microsoft.

I thought I'd get that in before too many other people do. I have better justification than most, as I *am* Jon Skeet. I saw the list yesterday, and we've been gently laughing about it at work.

Somewhere, the difference between fame and accomplishments has been lost. Don't get me wrong, I'm not a bad coder. I'm pretty knowledgeable about C# as a language, although details of writing *applications* in C# is a different matter. I'm pretty good at expressing technical concepts, and that's really useful in various contexts (Stack Overflow, books, screencasts, and of course work). But none of these are a patch on what some of the others on the list have accomplished.

As a Googler, I know a *bit* about what Jeff Dean and Sanjay Ghemawat have done - and it's obvious I'm not in the same league. The code I'm probably proudest of is Noda Time (my .NET date/time library) which has a few thousand users, if that. I hope I've had an impact everywhere I've worked, but it just isn't on the same scale as many of the other members of the list (let alone the many thousands of other notable programmers).

It's pretty clear I'm not actually on the list because of my coding skills - it's just due to Stack Overflow reputation. That indicates *something*, but it's definitely not the kind of measure you'd sensibly use to compare two programmers. Just as I'm proud of Noda Time, I'm proud of being able to help a lot of people on Stack Overflow - but I'm not under the delusion that even that's on the same level of impact as an awful lot of other coders.

For what it's worth, if I could substitute one other name for mine, it would be Eric Lippert. I'm not sure he's really be in the "top 14" or even whether that's meaningful - but I'd say he's at least *more* worthy of being there than I am.

It's not always "in your current time zone" - it depends on the "kind" of the DateTime. If you use DateTime.Now you will indeed get a value which is in your current system time zone. And I think you meant either DateTime.UtcNow or DateTimeOffset.UtcTicks rather than DateTime.UtcTicks...there's no such property as DateTime.UtcTicks.

When it comes to using the system time zone, It's not about "those iron age societies" using daylight saving - it's more about DateTime basically always representing some sort of "local" date, either in your local time zone, UTC, or an unspecified time zone. That's a very broken design, but not (IMO) in the way that you claim it to be.

Likewise it's entirely reasonable IMO to ignore "the" Julian/Gregorian shift in 1752, partly as it happened in different years depending on the place(and Sweden is particularly strange in this regard). All kinds of aspects of a date/time become weird if you swtch calendar system - and the DateTime type *only* represents the Gregorian calendar system. (If you give it a different one in the constructor, it effectively translates the value into the Gregorian calendar.) Again, I view that as a broken design - but not because of "the" 1752 shift.

So yes, there are plenty of valid criticisms of .NET's date/time handling, but yours didn't quite hit the mark for me.

The support for date and time handling in .NET is deplorable too, in my view. If it weren't, I wouldn't have bothered to create the Noda Time library (http://nodatime.org) which I'd like to think does a rather better job.

Having a single type (well, two with DateTimeOffset) to represent all kinds of different concepts is simply a bad idea. See my rant about this for more details:
http://noda-time.blogspot.co.uk/2011/08/what-wrong-with-datetime-anyway.html

There's an obvious potential correlation between high scores and plenty of questions being available though.

Hitting the rep cap (200) each day is relatively straightforward, which leaves only accepted answers (and bounties). If there aren't many questions in your area of expertise, you could easily end up with only 260 per day despite being incredibly savvy.

I'm lucky that my two areas of "reasonable competence" (I wouldn't quite go as far as expertise) are Java and C#, both of which have plenty of questions available. Whilst there's obviously more competition in those topics too, it's a fairly "target rich environment" so to speak.

From the summary: "in fear of being on the brink of another nuclear [sic] WAR."'

From the article: "in fear of being on the brink of another nucliar [sic] WAR".

It would help if posters didn't correct spelling for words which are followed by [sic].