Re: Usage of the DateAndTime TC

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Steve Moulton writes:

Steve> I have no argument with either a or b.  Juergen, I would like
Steve> to know what costs approach a has; initially it would have been
Steve> the approach I would have favored.

If you update the MIB object to use '0000010100000000'H instead of
'0000000000000000'H, then you have fixed the MIB but broken fielded
implementations that return or expect '0000000000000000'H. So the
right thing would be to deprecate the objects and to provide new
ones. And the managers would still need some additional logic to deal
with them correctly.

Steve> The only time I have dealt with DateAndTime is in implementing
Steve> host resources MIB, and it was simply not a problem there
Steve> (since the targets I was working with had some concept of
Steve> date).

The HOST-RESOURCES-MIB actually gets this right (even in RFC 1514).

Steve> So I am a bit puzzled about how to represent this value
Steve> in a management application.  Should this be something like
Steve> "00-0-0,0:0:0.0" (not very readable, but clearly communicates
Steve> the idea), "00-1-1,0:0:0.0" (both following the display hint)
Steve> or maybe "no date"?

I think this is a design choice. The scotty code simply applies the
DISPLAY-HINT and shows "0-0-0,0:0:0.0". The scli code will recognize
the missing DateAndTime value and show "-".

Steve> A different issue: Please pardon my cultural ignorance on this
Steve> question.  Americans tend to say that 2/5/2001 is February 5,
Steve> where Europeans say that it is May 2nd.  Is 2001/2/5
Steve> unambiguously yyyy/mm/dd or would some consider it yyyy/dd/mm?
Steve> I know the usage is spelled out in RFC2579, but I'd like to
Steve> make sure what a management app displays is ambiguous de facto,
Steve> as well as de jure.

I personally can only recommend to use the ISO date format "yyyy-mm-dd
hh:mm:ss" as in "2001-10-18 12:19:18 +02:00" (which is almost the
DISPLAY-HINT format defined in RFC 2579). (Note that this format
ignores the deci-seconds - something I personally never had problems
with so far - but it depends on the MIB objects that use DateAndTime.)
My observation is that more and more software package which do not
support proper localization use this format as it seems to have little
changes of mis-interpretation. For more details and some other views
on this subject read <draft-ietf-impp-datetime-05.txt>.

/js