When I described the two ways that the TIME_ZONE_INFORMATION structure represents the rules for daylight saving time, commenter Voo argued (and I hope I interpreted the message correctly) that either there should be two functions, one for each of the ways, or have Get­Time­Zone­Information­For­Year function calculate the day automatically from the week and return that. That way, callers always see the correct day.

Okay, there are multiple things in play here, but they all boil down to “no code is an island”.

If all you needed to support was a way to answer the question “When does daylight saving time start and end in this specific year”, then certainly the nth week rules could be interpreted by the Get­Time­Zone­Information­For­Year function, so that all that came out of the function was a specific date and time.

But that’s not the only function that deals with time zone information. For starters, we have Get­Time­Zone­Information. Since this function is not dependent on the year, it wouldn’t know what year to use to calculate the date on which the third Sunday falls. It would have to leave the structure in generic form.

Now, maybe you say, “Yeah, these two functions return the same structure, and you just have to know that one of the functions will autoconvert and the other won’t.” Some people will find that confusing.

Maybe you solve that problem by saying, “These two functions return different structures, reflecting their different natures.” Some people will be frustrated by that, because they will have to write two versions of the same function, one for each structure.

(I’m not event going to bother adding Get­Dynamic­Time­Zone­Information. to the mix.)

And then there’s the question of whether it’s okay that the Get function returns a structure that cannot be passed into the corresponding Set function. (Which is a bit of a pointless question here, seeing as there is no Set­Time­Zone­Information­For­Year function, but maybe someday it will show up.) It also means that you cannot compare two TIME_ZONE_INFORMATION structures from different years to see whether the time zone transition rules are the same in those years. (This is, admitted, a fringe scenario.)

Two functions seems the less crazy way out. There would be a Get­Unexpanded­Time­Zone­Information­For­Year which returns the unprocesed information and a Get­Expanded­Time­Zone­Information­For­Year that does the date lookup for the appropriate year. Though personally, I would keep Get­Time­Zone­Information­For­Year as-is and add a Calculate­Daylight­Saving­Transition­Dates­For­Year function. That way, you could use it to expand other things.

I suspect no such Calculate­Daylight­Saving­Transition­Dates­For­Year function exists because the kernel folks have a general bias against writing functions that you could have written yourself, so that they can focus on writing functions that you can’t write yourself because it requires special access to things that only the kernel has access to. (Like querying the current time zone.)