Time zones issues with TimeDateFoundEnum

[zport]

Unless you're in the EST, this seems to work incorrectly or need finagling to get to work right.

Reported by a vendor.

[solind]

Hi Zack, there is no TimeDateFoundEnum in the entire OVAL schema. What's this specifically in reference to?

[zport]

Hi Dave, sorry for the confusion there. The issue is with DateTimeFormatEnumeration (I corrected the issue title); it sounds like there have been issues with getting it to work correctly when in a location outside of the eastern standard timezone. My understanding of the issue was that in some cases, the results only matched if the user was in that timezone, and that if the year/month/date were not specified, values defaulted to EST but then didn't match up with the values collected. Any knowledge regarding this on your end?

[solind]

Perhaps this is a complaint regarding an issue with a specific product?

There is really not a technical limitation regarding time-zones with the enumeration as I see it.

If a content author needs to be able to specify a certain date in OVAL content, that can be accomplished using either win_filetime (the number of 100-nanosecond tics since midnight Jan 1, 1601 UTC) or seconds_since_epoch (seconds since Jan 1, 1970 UTC).

Otherwise, we presume that the other formats are there for the purpose of parsing formatted string time depictions originating on the target device -- in which case, the timezone of the target device can be assumed.

However, I would agree that it would be prudent for us to document that assumption in the schema and specification docs.