Quantcast

CPE Dictionary: Timestamps lack timezone

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

CPE Dictionary: Timestamps lack timezone

Jan-Oliver Wagner-3
Hello,

we realized that the CPE content uses timestamps without timezone.
According to ISO 8601 this means it is UTC.

The CVE content does use timestamps with timezone (-4 for EST).
So, this at least is a bit inconsistent.

Should we assume all CPE is in UTC? Or does it make sense to fix
the whole CPE dictionary by adding -4 as timezone?

This might look like a minor issue, but it prevents some of our plausibility
and consistency checking to work properly.

Best regards

        Jan

--
Dr. Jan-Oliver Wagner |  ++49-541-335084-0  |  http://www.greenbone.net/
Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 202460
Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CPE Dictionary: Timestamps lack timezone

Booth, Harold
Consumers of the CPE dictionary please read the following and provide feedback:

  After looking at the file and the code for generating the dictionary, it appears that the situation was not optimal. The time zone was not specified for the XML output, while the time zone used was the current time zone for the server (-4 or -5 depending on which time of year). We have modified the code to now output the time in UTC and to be explicit about it.

  The new date time format will look like something like:

    <timestamp>2011-11-14T17:58:41.078Z</timestamp>
or
    <meta:item-metadata modification-date="2010-12-14T19:38:32.197Z" [... other attributes omitted ...] />

  This will now make the time zone explicit, but that leads me to the following question for everyone else:

How will deploying this change affect you?

In the past we have made changes to correct issues, and that has caused difficulty on occasion. The change made in this case will cause the values that currently appear for the date time types within the CPE dictionary to now be UTC times. This may be what others had assumed previously, but the Z at the end is one of the proper ways to indicate the UTC time zone (see section 3.2.7.3 http://www.w3.org/TR/xmlschema-2/); the current condition with the absence of a time zone (defined as a "Local" time or untimezoned time) is ambiguous in our case (see section 3.2.7).

Feedback on this topic is welcomed.

-----Original Message-----
From: Jan-Oliver Wagner [mailto:[hidden email]]
Sent: Friday, November 11, 2011 2:01 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] CPE Dictionary: Timestamps lack timezone

Hello,

we realized that the CPE content uses timestamps without timezone.
According to ISO 8601 this means it is UTC.

The CVE content does use timestamps with timezone (-4 for EST).
So, this at least is a bit inconsistent.

Should we assume all CPE is in UTC? Or does it make sense to fix
the whole CPE dictionary by adding -4 as timezone?

This might look like a minor issue, but it prevents some of our plausibility
and consistency checking to work properly.

Best regards

        Jan

--
Dr. Jan-Oliver Wagner |  ++49-541-335084-0  |  http://www.greenbone.net/
Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 202460
Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CPE Dictionary: Timestamps lack timezone

Jan-Oliver Wagner-3
On Monday, 14. November 2011, Booth, Harold wrote:

> Consumers of the CPE dictionary please read the following and provide feedback:
>
>   After looking at the file and the code for generating the dictionary, it appears that the situation was not optimal. The time zone was not specified for the XML output, while the time zone used was the current time zone for the server (-4 or -5 depending on which time of year). We have modified the code to now output the time in UTC and to be explicit about it.
>
>   The new date time format will look like something like:
>
>     <timestamp>2011-11-14T17:58:41.078Z</timestamp>
> or
>     <meta:item-metadata modification-date="2010-12-14T19:38:32.197Z" [... other attributes omitted ...] />
>
>   This will now make the time zone explicit, but that leads me to the following question for everyone else:
>
> How will deploying this change affect you?

No effects on our side. We are assuming UTC already. Only the times will then shift by 4hrs
when running the respective update.

The notation with "Z" is a valid standard and is suported by timestamp conversion/parsing APIs.
Personally, I don't care but wouldn't use of same scheme as in CVE make sense for consistency sake?

Best regards

        Jan

--
Dr. Jan-Oliver Wagner |  ++49-541-335084-0  |  http://www.greenbone.net/
Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 202460
Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner
Loading...