Wednesday, May 12, 2010

Gotta learn to keep my mouth shut

I think it was my fault: I recall making the fateful declaration, a long time ago, that date and time values representing actual times such as the time an alarm was issued (e.g. 3:23:52.01 on Thursday 4/01/2010), should not contain "wildcard" or pattern-matching values (e.g. 3:nn:nn.nn on Thursdays in April, any day of month, any year). And in fact a little research shows it was just about 10 years ago when I first submitted a proposal to make this concept part of the standard.

What seemed so simple at first became complex, and languished while more critical changes went ahead, but the proposal finally went to public review this spring, and it drew a lot of comments that required a LOT of debate in today's Objects & Services Working Group meeting. One comment alone, titled "Relax definition for single date by allowing day of week to be unspecified," required an hour and a half of serious and lengthy discussion.

In the process we digressed into a number of other time-related issues, such as when the BACnet standard is calling for the use of "local time" as opposed to "UTC time" (f.k.a. Greenwich Mean Time). The answer seems obvious and I have never seen an implementation that did anything differently from what we would expect. But the rule is stated nowhere in the standard, so I initiated the process for getting this into the standard for all time and e-mailed the requisite paperwork to ASHRAE during the meeting. ASHRAE responded in short order with the response form for submitting tpo the committee, I approved it, and our Chair will hopefully have it by now (he was unaware it was coming), and perhaps we can approve in the the plenary session tomorrow of Friday.

But after we finished reviewing, and deciding on the responses to, the public review comments we were finally able to start on new material before the day ended.

Tomorrow we kick off the first day of a day and a half of the plenary session, where the formal official business of the committee is executed.

But I almost feel guilty for the effort I caused a decade ago, when it might have been simpler to just allow implementations to represent actual times with pattern-matching values where elements of the time (hundredths of a second, seconds, etc.) are not known or the implementer didn't want to calculate them (day of week)

Mayhbe I just gotta learn to keep my mouth shut.

Update: Just to give credit where credit is due, I believe Coleman took over this proposal a couple of years ago and got it to passage.

1 comment:

  1. Thanks for the mention, Bill, but I was only standing on the shoulders of a giant.