Re: [Freeipmi-devel] [bug #38798] timestamps are interpretted as UT rather than localtime, violating IPMI 2.0 section 37

[Al Chu]

On Thu, 2013-05-02 at 16:34 +0200, Liebig, Holger wrote:
> > 
> > I for one think that's a great idea. Do you happen to know of BMCs which
> > actually support the "Get SEL Time UTC Offset" command?
> [Liebig, Holger] 
> I know at least one BMC base firmware provider which supports these 2
> optional IPMI cmds in current firmware versions. But (unfortunately)
> logs by default into the SEL with local time timestamps and in
> addition provides the UTC offset of the running embedded O/S with the
> Get SEL Time UTC cmd - which in my opinion is not correct. A BMC
> should log either in local time or in UTC and provide information
> about the current UTC offset of the SEL in the latter case, but not
> both at the same time.
> 
> My understanding is: 
> Get SEL Time UTC Offset not supported or returning unspecified
> (0x7FFF) the SEL is operating in local time. Any other value within
> the valid range of -1440 ... 1400 is indicating the SEL running in UTC
> mode. Adding the offset to the SEL timestamps results in calendar
> time, quote from the man page: "When interpreted as an absolute time
> value, it represents the number of seconds elapsed since the Epoch,
> 1970-01-01 00:00:00 +0000 (UTC)". Both localtime_r() and gmtime_r()
> take calendar time as input, which would represents your usage model
> of converting #1 into #2 or #3 below. 

I don't think that's the case?  localtime_r() and gmtime_r() assume
input is UTC time.  gmtime_r() only converts the inputted timestamp into
the broken down time (struct tm)?

I've been actually trying to figure out the best/most portable/thread
safe way to convert from a localtime to UTC time and haven't quite
figured it out.  One developer in my group said I may need to muck w/
the timezone fields within 'struct tm', which seems scary.  Mucking w/
the TZ environment variable is (AFAIK) not thread safe.  I'm thinking
manual calculation is probably the most safe/portable (i.e. calculate
the difference between the gmtime & localtime results and adjust
appropriately).

> > 
> > One point of frequent confusion is that there are actually 3 potential
> > interpretations of a time-stamp:
> > 1. Local time for the managed system/BMC 2. Local time for the management
> > console 3. UTC
> [Liebig, Holger] 
> It can be even more complicated, depending if the BMC has its own
> RTC/time source (better), or is using the systems RTC (bad). If the
> BMC is using the system RTC and depending on the O/S and the
> configuration of the system, the system RTC can reflect local time
> (Windows default) or UTC (Linux default). This can be changed for both
> of them to match each other, but the default is vice versa and dual
> booting is fun. See also
> http://mikebeach.org/2011/04/10/windows-linux-dual-boot-system-time-issues/ . 
> Additional problems arise, when the O/S is operating the system RTC in UTC 
> mode, but the BMC is interpreting the RTC as local time without a standard 
> way of knowledge of the RTC mode of the running O/S. So we might end up with 
> multiple command line options:
> 
> --interpret-sel-time-as-localtime: 
> If "Get SEL UTC offset" returns unspecified or is not supported pass the 
> timestamp unmodified into gmtime_r()

This was what I was going to have output as default.

> If "Get SEL UTC offset" valid pass the timestamp + offset into localtime_r()
>
> --interpret-sel-time-as-utc
> If "Get SEL UTC offset" returns unspecified or is not supported pass the 
> timestamp unmodified into localtime_r()

Yup, this was going to be my --assume-time-utc like option.

> If "Get SEL UTC offset" valid pass the timestamp + offset into gmtime_r()
> 
> --ignore-sel-time-utc-offset
> Workaround for the case mentioned above when the BMC is logging with
> local time timestamps and is also returning a valid SEL Time UTC
> offset. --> pass the timestamp unmodified into gmtime_r()
> 
> And the combinations:
> --interpret-sel-time-as-utc --ignore-sel-time-utc-offset
> ??? use UTC offset from management console?
> 
> --interpret-sel-time-as-localtime --ignore-sel-time-utc-offset
> pass the timestamp unmodified into gmtime_r()

I need to look on my systems and see how many support the get/set SEL
UTC time commands.  If very few do, I think that implementing something
that tries to use it is perhaps fruitless.

Or perhaps there would be option for the user to tell FreeIPMI to use
them at their risk?

One colleague made a great suggestion of that FreeIPMI should always
offer a --utc-offset=XXX option so that users can also just explicitly
list whatever they want.

Al

> > 
> > The IPMI specification defines time-stamps sent from the management
> > controller as format #1. If the management console can get the managed
> > system's UTC offset (e.g. using "Get SEL Time UTC Offset"), then it could
> > convert the timestamps from format #1 to either #2 or #3 (for display,
> > storage or comparison purposes).
> 
> [Liebig, Holger] 
> As I stated above, my understanding is that this command is for solely for 
> the SEL Time UTC offset and **not** a generic "Get BMC Time UTC offset". 
> 
> 
> Let me know if you have comments or input regarding this.
> 
> Thanks,
> Holger
> 
> > 
> > -----Original Message-----
> > From: address@hidden
> > [mailto:address@hidden On Behalf Of
> > Liebig, Holger
> > Sent: Thursday, April 25, 2013 10:51 PM
> > To: address@hidden
> > Subject: Re: [Freeipmi-devel] [bug #38798] timestamps are interpretted as
> > UT rather than localtime, violating IPMI 2.0 section 37
> > 
> > Al,
> > If this gets fixed (and if possible) could you please include handling of
> > the optional Get SEL Time UTC offset command introduced in Errata 4? This
> > can be used to convert non localtime timestamps back to calendar time and
> > come in handy when a BMC is configured to use a NTP server. From calendar
> > time you can then convert it to localtime or UTC using the appropriate
> > libc functions (localtime_r() and gmtime_r()). And as generic improvement:
> > customers with BMC's around the world might appreciate a command line
> > option to display SEL timestamps in GMT in addition to localtime in order
> > to correlate events to each other.
> > 
> > Thanks,
> > Holger
> > 
> 
> _______________________________________________
> Freeipmi-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/freeipmi-devel
-- 
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory