Parsing UTC Time

It all started with simple requirement: there is UTC time string (e.g. 21:00) and you should parse it into UTC DateTime. Simplest code ever:

var time = DateTime.ParseExact(text, "HH:mm",
                               CultureInfo.InvariantCulture,
                               DateTimeStyles.NoCurrentDateDefault);

Only issue is that it does not work. While it looks good on first look, more careful investigation shows that its type is not Utc but Unspecified. While this might not seem as a major pain, it does make a difference.

Let’s assume that you send proper UTC time to some function that does time.ToUniversalTime(). Function will just return exactly same time back. If you do same with Unspecified time, function will adjust it for time zone and you will get back completely different time than what you started with.

Well, fixing this is easy, just add AssumeUniversal flag:

var time = DateTime.ParseExact(text, "HH:mm",
                               CultureInfo.InvariantCulture,
                               DateTimeStyles.NoCurrentDateDefault
                             | DateTimeStyles.AssumeUniversal);

Unfortunately it does not work. While description says “If no time zone is specified in the parsed string, the string is assumed to denote a UTC”, flag actually causes our time to be Local. Weird.

To properly parse time you need one more flag:

var time = DateTime.ParseExact(text, "HH:mm",
                               CultureInfo.InvariantCulture,
                               DateTimeStyles.NoCurrentDateDefault
                             | DateTimeStyles.AssumeUniversal
                             | DateTimeStyles.AdjustToUniversal);

This will finally cause our time to be of Utc kind.

Code sample is available.

More Ohms Please

One of first things that you might learn as electronic hobbyist is that you should have 20 mA running through your indicator LEDs. For example, if you have 5 V power supply and your LED has voltage drop of 2V at 20 mA just give it 150 ohm resistor and you are golden.

And that is wrong. This recipe was valid 20 years ago but it is not something you should follow these days. If you have 20 mA coursing through LED, that is BRIGHT as hell. When you work in dark, every look at such device blinds you for minutes.

Don’t misunderstand me, I like to see some indication that device is alive but 1 mA or less should do the trick. These new LEDs are extremely efficient with their output and, while they still specify their current at 20 mA (or even higher), they will be bright enough at lower currents also.

PS: This rant is only about indicator LEDs; if your device needs to light-up the room, so be it.

Do I Have This Certificate?

For one build script I had to know whether certain certificate is present. It took me a while until I found Certutil. Assuming that you know a hash of desired key (and you should) command is simple:

CERTUTIL -silent -verifystore -user My e2d7b02c55d5fe76540bab384d85833376f94c13

In order to automate things you just need to extend it a bit to check exit code:

CERTUTIL -silent -verifystore -user My e2d7b02c55d5fe76540bab384d85833376f94c13
IF ERRORLEVEL 1 ECHO No certificate found.

All nice-and-dandy except that it does not work. For some reason Certutil always returns exit code 0 regardless of success. But not all is lost, command does set ERRORLEVEL environment variable (not the same thing as exit code):

CERTUTIL -silent -verifystore -user My e2d7b02c55d5fe76540bab384d85833376f94c13
IF NOT %ERRORLEVEL%==0 ECHO No certificate found.

Keys.RButton | Keys.ShiftKey | Keys.Alt

Let’s assume very simple code for purpose of key detection:

protected override bool ProcessCmdKey(ref Message msg, Keys keyData) {
    Debug.WriteLine(keyData);
}

Whichever key you press you will get short output in Output window. Totally boring.

But interesting thing happens when you press Alt key. Output is (sort of) as expected:

Menu, Alt

However, if you put breakpoint there and hover your mouse over keyData you will see that value is actually Keys.RButton | Keys.ShiftKey | Keys.Alt. Which one is it?

Answer is that it does not really matter. If we check values in Keys enumeration we will find following:

RButton  = 2
ShiftKey = 16
Menu     = 18
Alt      = 262144

We can see or as simple addition and thus Menu + Alt will give you 262162. Same result can also be obtained with RButton + ShiftKey + Alt.

CLR will get just integer with value of 0x40000 (262144 in decimal) from Windows. No matter what you do, it stays in integer domain. When you say Keys.Menu you are just saying 18 in human readable way. So for any text display code actually needs to guess what combination will give that result.

Code that handles string conversion goes from highest element and matches Alt and Menu. Code that handles tooltips matches values from lower end and thus it will find RButton, ShiftKey and Alt. Computer cannot say that one solution is better than other.

Regardless which combination you choose result will be the same.

Something Happened

Going around Windows Store I managed to trigger an error “Something happened and your purchase can’t be completed.”

Maybe I am too much of an power user but this message bothers me.

Did problem happen on my computer or remote server? Is author of application at fault? Do I even have connection to server? Am I in wrong region? If I try again will it help? Should I try again now or at some later time? Is error already reported to someone or should I report it?

So many questions and just a short unhelpful message to answer them all…