#2737 sblim-cmpi-base datetime values do not adjust for DST

[Dave Heller]

In short, the proposal is to have cmpi-base return DST-adjusted values for datetime.

When returning a property containing a datetime, such as from an EI or EIN call, the provider does not adjust for daylight sayings time, but instead will return the value reflecting the system's local timezone in standard time only, regardless of whether DST is in effect for the given datetime.

The affected properties are:

Linux_ComputerSystem.CurrentTimeZone
Linux_ComputerSystem.LocalDateTime
Linux_ComputerSystem.LastBootUpTime
Linux_ComputerSystem.InstallDate
Linux_UnixProcess.CreationDate

For example: in the eastern US, a time corresponding to midnight UTC (say: 20140815000000.000000-000) will be always returned in standard time (EST), even though the date falls in the range defined for daylight savings time (EDT) for this timezone. That is, the following query will return:

$ wbemcli -nl ei http://mybox:5988/root/cimv2:Linux_OperatingSystem LocalDateTime,CurrentTimeZone
mybox:5988/root/cimv2:Linux_OperatingSystem.CSCreationClassName="Linux_ComputerSystem",CSName="mybox",CreationClassName="Linux_OperatingSystem",Name="mybox"

-LocalDateTime=20140814190000.000000-300
-CurrentTimeZone=-300

rather than the expected:

-LocalDateTime=20140814200000.000000-240
-CurrentTimeZone=-240

The UTC offset (i.e. the part following the +/) will always reflect the timezone's standard offset, never the DST-adjusted offset.

Note that the value is not wrong. Recall that any given "absolute time" can be represented by a number of different values in "localtime": 24 possible values if one considers just the common timezones; 24*60 values if one considers all the possible values represented by a UTC offset in minutes.

So, the value is correct; it is simply represented with a UTC offset different than the one expected.

[Dave Heller]

The CMPI standards seem to be vague on the correct behavior here.

DSP0004, section 5.2.4 - "Datetime Type", with respect to the "UTC offset" value:

utc and s (+/-) indicate the UTC offset of the time zone in which the time expressed by the other
fields is the local time, *including any effects of daylight savings time*.

Which simply states that all fields in the datetime must be consistent with the UTC offset field (i.e. a correct value), whether the value is given in DST or not. It makes no statement about whether the DST representation is required.

The DMTF schema for class CIM_OperatingSystem states (http://schemas.dmtf.org/wbem/cim-html/2.35.0/CIM_OperatingSystem.html):

CurrentTimeZone - indicates the number of minutes the OperatingSystem is offset from GMT
LocalDateTime - OperatingSystem's notion of the local date and time of day

which also makes no statement as to whether the values should be adjusted for DST.

[Dave Heller]

While the standards do not say that a DST representation is required, they don't say it is wrong. So it seems to make sense to return DST-adjusted values where appropriate.

Appropriate here means: corresponding to the time of the event. For example: if machine was last booted on a date in EST, LastBootUpTime should return a value in EST, even if the query is done on a date in EDT. Conversely, CurrentTimeZone and LocalDateTime should reflect a date in EDT, if the query is done in EDT.

Put another way: we should adjust for DST based on the value we are translating.

This change should not break any client code, as long as that code is properly processing all fields in the CMPIDateTime.

This is the proposal. Feedback welcome.

[Dave Heller]

The attached patch contains the proposed changes. Linux_ComputerSystem.CurrentTimeZone and LocalDateTime were correct, just not adjusted for DST. However, LastBootUpTime, InstallDate and Linux_UnixProcess.CreationDate were returning incorrect values in some cases. These are all fixed, except for InstallDate, which is excluded for now since that module has other issues.

Note that CurrentTimeZone and LocalDateTime are retrieved "atomically" in the IE call; that is, the two properties will always return the same UTC offset in a single query, making it safe in case the query occurs exactly at the time of the DST change.

As always, the provider honors the value of the environment variable TZ, if set. This of course applies to the CIMOM's environment, not the client's. See "man tzset" for an explanation of proper TZ values. If TZ is not set it falls back to the system default, which is typically the value stored at /etc/localtime. This is covered in "man tzset" as well.

The returned values should be correct for any value of TZ

[Dave Heller]

Committed to git master for cmpi-base 1.6.3 as [20e84c]

[Vitezslav Crhonek]

Hello Dave,

I'm updating to latest sblim-cmpi-base release in Fedora and this change causes a problem while getting instance of Linux_OperatingSystem:

CIM_ERR_FAILED: CMNewDateTimeFromChars for property LocalDateTime failed.

This is relevant part of debug output:
[4] [10/23/2014 13:27:35] --- OSBase_OperatingSystem.c(307) : --- get_os_localdatetime() called
[4] [10/23/2014 13:27:35] --- OSBase_Common.c(266) : --- sse_to_cmpi_datetime_str() called for sse=1414067255 local=1 adj_dst=1

[4] [10/23/2014 13:27:35] --- OSBase_Common.c(289) : --- sse_to_cmpi_datetime_str() : exiting, returned value: +120
[4] [10/23/2014 13:27:35] --- OSBase_OperatingSystem.c(311) : --- get_os_localdatetime() exited : +120

Obviously, the return value of get_os_localdatetime is not correct. The reason is here:
sprintf(dt, "%s%+04d", dt, offset);

The memory from/to where sprintf copy should not overlap. See [1] - "If copying takes place between objects that overlap as a result of a call to sprintf() or snprintf(), the results are undefined.".

Attached patch fixes the issue for me.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/sprintf.html

[Dave Heller]

Hrmm... yes, I took a shortcut there but I guess that wasn't a good idea. The sprintf() isn't exactly the same thing as an assignment. It worked in my testing but I guess I just got away with it. Interesting that I get no compiler warning, even with -Wextra.

I checked in your patch, thanks. I'm going to do a respin of the package release that will take it to v1.6.4. If you see any other problems before I do, please let me know! Thx -Dave

[Dave Heller]

Committed to git master for cmpi-base 1.6.4 as [a556de]