(I see on the article that there are comments about this, with one trying to excuse it as "The influence is so great that its greatness is very obvious, making it unlikely that anyone would believe it to be lower than the actual value." Nope, I don't buy that at all. It's just plain wrong.)

> It's difficult to underestimate the massive influence that Disney's 1982 cult science fiction film, TRON, had on both the film industry

Really? As in, it had *so* little influence that in order to underestimate the influence, I'd have to estimate that it had no influence at all, or negative influence?

I don't see why it's apparently so hard to get "it's difficult to overestimate" right here. (Obviously this isn't the sole example. It's a source of frequent frustration - with "understate/overstate" causing similar difficulties.)

There are multiple articles linked in the post, and explicit mentions of multiple models. Yes, the Register one only refers to a 100 billion parameter model; the Tom's Hardware and South China Morning Post articles specifically talk about a 1 trillion parameter model. So does the post itself:

> The South China Morning Post says the unnamed model has 1 trillion parameters, according to China Telecom, while the TeleChat2t-115B model has over 100 billion parameters.

So, two models: one with 100 billion parameters, and one with 1 trillion parameters - at least allegedly. While we may or may not trust the source, there's no point in claiming that the trillion parameter model isn't mentioned.

Sure - this was just "all transitions" within the first half of 2021.

As far as I can tell, only North America changes clocks today. Calling that "much of the world" isn't a good look, IMO.

Here's a list of transition dates in the first half of 2021, grouped by UTC date, listing the time zone ID - and of course, there are plenty of places that don't observe daylight saving time at all.

2021-01-16
Pacific/Fiji

2021-01-31
Africa/Juba

2021-03-14
America/Adak, America/Anchorage, America/Atka, America/Boise, America/Cambridge_Bay, America/Chicago, America/Denver, America/Detroit, America/Edmonton, America/Ensenada, America/Fort_Wayne, America/Glace_Bay, America/Goose_Bay, America/Grand_Turk, America/Halifax, America/Havana, America/Indiana/Indianapolis, America/Indiana/Knox, America/Indiana/Marengo, America/Indiana/Petersburg, America/Indiana/Tell_City, America/Indiana/Vevay, America/Indiana/Vincennes, America/Indiana/Winamac, America/Indianapolis, America/Inuvik, America/Iqaluit, America/Juneau, America/Kentucky/Louisville, America/Kentucky/Monticello, America/Knox_IN, America/Los_Angeles, America/Louisville, America/Matamoros, America/Menominee, America/Metlakatla, America/Miquelon, America/Moncton, America/Montreal, America/Nassau, America/New_York, America/Nipigon, America/Nome, America/North_Dakota/Beulah, America/North_Dakota/Center, America/North_Dakota/New_Salem, America/Ojinaga, America/Pangnirtung, America/Port-au-Prince, America/Rainy_River, America/Rankin_Inlet, America/Resolute, America/Santa_Isabel, America/Shiprock, America/Sitka, America/St_Johns, America/Thule, America/Thunder_Bay, America/Tijuana, America/Toronto, America/Vancouver, America/Winnipeg, America/Yakutat, America/Yellowknife, Atlantic/Bermuda, CST6CDT, Canada/Atlantic, Canada/Central, Canada/Eastern, Canada/Mountain, Canada/Newfoundland, Canada/Pacific, Cuba, EST5EDT, MST7MDT, Mexico/BajaNorte, Navajo, PST8PDT, US/Alaska, US/Aleutian, US/Central, US/East-Indiana, US/Eastern, US/Indiana-Starke, US/Michigan, US/Mountain, US/Pacific

2021-03-21
Asia/Tehran, Iran

2021-03-25
Asia/Amman, Asia/Damascus

2021-03-26
Asia/Gaza, Asia/Hebron, Asia/Jerusalem, Asia/Tel_Aviv, Israel

2021-03-27
Asia/Beirut

2021-03-28
Africa/Ceuta, America/Asuncion, America/Godthab, America/Nuuk, America/Scoresbysund, Antarctica/Troll, Arctic/Longyearbyen, Asia/Famagusta, Asia/Nicosia, Atlantic/Azores, Atlantic/Canary, Atlantic/Faeroe, Atlantic/Faroe, Atlantic/Jan_Mayen, Atlantic/Madeira, CET, EET, Eire, Europe/Amsterdam, Europe/Andorra, Europe/Athens, Europe/Belfast, Europe/Belgrade, Europe/Berlin, Europe/Bratislava, Europe/Brussels, Europe/Bucharest, Europe/Budapest, Europe/Busingen, Europe/Chisinau, Europe/Copenhagen, Europe/Dublin, Europe/Gibraltar, Europe/Guernsey, Europe/Helsinki, Europe/Isle_of_Man, Europe/Jersey, Europe/Kiev, Europe/Lisbon, Europe/Ljubljana, Europe/London, Europe/Luxembourg, Europe/Madrid, Europe/Malta, Europe/Mariehamn, Europe/Monaco, Europe/Nicosia, Europe/Oslo, Europe/Paris, Europe/Podgorica, Europe/Prague, Europe/Riga, Europe/Rome, Europe/San_Marino, Europe/Sarajevo, Europe/Skopje, Europe/Sofia, Europe/Stockholm, Europe/Tallinn, Europe/Tirane, Europe/Tiraspol, Europe/Uzhgorod, Europe/Vaduz, Europe/Vatican, Europe/Vienna, Europe/Vilnius, Europe/Warsaw, Europe/Zagreb, Europe/Zaporozhye, Europe/Zurich, GB, GB-Eire, MET, Poland, Portugal, WET

2021-04-03
Antarctica/Macquarie, Antarctica/McMurdo, Antarctica/South_Pole, Australia/ACT, Australia/Adelaide, Australia/Broken_Hill, Australia/Canberra, Australia/Currie, Australia/Hobart, Australia/LHI, Australia/Lord_Howe, Australia/Melbourne, Australia/NSW, Australia/South, Australia/Sydney, Australia/Tasmania, Australia/Victoria, Australia/Yancowinna, NZ, NZ-CHAT, Pacific/Apia, Pacific/Auckland, Pacific/Chatham, Pacific/Norfolk

2021-04-04
America/Bahia_Banderas, America/Chihuahua, America/Mazatlan, America/Merida, America/Mexico_City, America/Monterrey, America/Santiago, Chile/Continental, Chile/EasterIsland, Mexico/BajaSur, Mexico/General, Pacific/Easter

2021-04-11
Africa/Casablanca, Africa/El_Aaiun

2021-05-16
Africa/Casablanca, Africa/El_Aaiun

Surely this should have been a plug-in for Kerbal Space Program. Fly your rocket in the game, order the real thing. Not holding my breath for same-day delivery though...

At that point, the ability to use this to replace DRAM becomes much more reasonable. If it were really just 1000x the writes of NAND, it would be far too short-lived to act as normal RAM... but if it's *really* the typical lifetime, things could get very interesting indeed...

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.