[DmtData] what is the correct format of date-time values

[bjhargrave]

Original bug ID: BZ#1938 From: Evgeni Grigorov <e.grigorov@prosyst.com> Reported version: R4 V4.3

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

Currently, DmtData date-time format is one of 'yyyyMMddThhmmss' or 'yyyyMMddThhmmssZ'. According TR-106, date-time values like 2011-01-15T00:00:00 are correct. If we support only a part of the possible formats, then we need to clarify that in the specification. Otherwise, the implementation must be extended.

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

I went through the OSGi Mobile and SyncML specifications. Collected info:

1. [OSGi Mobile] The specification doesn't use date and time formats. There is a leaf node: Log//LogResult//Time with the following description: " The value is the UTC based date and time of the creation of the log entry in basic representation, complete format as defined by ISO-8601 with the pattern yyyymmddThhmmssZ. For example: 20040720T221011Z " The node type is string.

2. SyncML MetaInfo specification: " If the value is date, then the format of the content is in ISO 8601 format with the century being included in the year [ISO8601]. If the value is time, then the format of the content is in ISO 8601 format. "

My suggestions:

1. Keep the current implementation of DmtData and clarify a little bit javadoc of FORMAT_DATETIME from " The node holds a String object that is interpreted as a dateTime type defined in ISO 8601. " to " The node holds a String object that is interpreted as a dateTime type defined in ISO 8601. The interpretation patter is CCYYMMDDThhmmss or CCYYMMDDThhmmssZ. "

2. A new issue will be posted for an update of TR-069 Utility methods.

Is it ok?

[bjhargrave]

Comment author: william.lupton@pace.com

ISO 8601 is not publicly available (AFAIK) but is summarised at http://en.wikipedia.org/wiki/ISO_8601.

It seems that there are two formats: basic and extended; extended uses the hyphen separators and (per the wiki page) is preferred

TR-069 uses the XML Schema dateTime type http://www.w3.org/TR/xmlschema-2/#dateTime, which is based on ISO 8601, but not all ISO 8601 values are valid XML values; the XML pattern is:

'-'? yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)?

The proposed patterns:

CCYYMMDDThhmmss CCYYMMDDThhmmssZ

...are not consistent with this. Furthermore, the XML pattern supports fractional seconds and time zones other than UTC.

Therefore I think that we need to extend the DmtData definition to incude fractional seconds and time zones (per the wiki page, these are not actually part of ISO 8601), and to provide utilities for converting the TR-069 XML format to and from the DmtData format.

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

ISO 8601 is not publicly available (AFAIK) but is summarised at http://en.wikipedia.org/wiki/ISO_8601.

It seems that there are two formats: basic and extended; extended uses the hyphen separators and (per the wiki page) is preferred

TR-069 uses the XML Schema dateTime type http://www.w3.org/TR/xmlschema-2/#dateTime, which is based on ISO 8601, but not all ISO 8601 values are valid XML values; the XML pattern is:

'-'? yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)?

The proposed patterns:

CCYYMMDDThhmmss CCYYMMDDThhmmssZ

...are not consistent with this. Furthermore, the XML pattern supports fractional seconds It's a problem. and time zones other than UTC. It can be always converted to UTC.

Therefore I think that we need to extend the DmtData definition to incude fractional seconds and time zones (per the wiki page, these are not actually part of ISO 8601), and to provide utilities for converting the TR-069 XML format to and from the DmtData format.

[bjhargrave]

Comment author: william.lupton@pace.com

and time zones other than UTC. It can be always converted to UTC. yes but then it won't read back in the same time zone that it was written

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

and time zones other than UTC. It can be always converted to UTC. yes but then it won't read back in the same time zone that it was written I thought that it's not a problem, because the parameter type is date-time i.e. ACS cannot expect that the representation will be same, but value will be same. If it is expected, the node type should be pure string and set/get will return same value representation. Is it correct in a typical BBF use case?

[bjhargrave]

Comment author: william.lupton@pace.com

and time zones other than UTC. It can be always converted to UTC. yes but then it won't read back in the same time zone that it was written I thought that it's not a problem, because the parameter type is date-time i.e. ACS cannot expect that the representation will be same, but value will be same. If it is expected, the node type should be pure string and set/get will return same value representation. Is it correct in a typical BBF use case?

I think that's OK

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

Evgeni, Could you summarize the conclusion ?

1. What Evgeni needs to add the Spec Draft.
2. What I need needs to add the javadoc (in the RI).

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

Evgeni, Could you summarize the conclusion ?

1. What Evgeni needs to add the Spec Draft.
2. What I need needs to add the javadoc (in the RI). The specification needs an update because the current data-time DmtData format doesn't cover the TR-069 date time format. Willaam, pointed that in Comment BZ#3. Based on that solution, we need an investigation about TR-069 PA Utility classes. They should process all possible TR-069 date-time formats.

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

[06.04.2011] Conference Call REG decided that the new DmtData format date-time will be fixed to cover TR dateTime type. The available ("old") info.dmtree.DmtData.FORMAT_DATE and info.dmtree.DmtData.FORMAT_TIME will not be modified, because the changes will be backward incompatible. The extended date-time pattern will be in a short format i.e. without separators like hyphen "-".

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

[06.04.2011] Conference Call REG decided that the new DmtData format date-time will be fixed to cover TR dateTime type. The available ("old") info.dmtree.DmtData.FORMAT_DATE and info.dmtree.DmtData.FORMAT_TIME will not be modified, because the changes will be backward incompatible. The extended date-time pattern will be in a short format i.e. without separators like hyphen "-".

My understanding is correct ?

• Steffen is responsible for updating the Javadoc.
• No need to modify TR069ParameterValue.getDmtData() impl (as it is): if (tr069Type.equals(TR069_TYPE_DATETIME)) { if ((format & DmtData.FORMAT_DATETIME) != 0) { try { data = new DmtData(value, DmtData.FORMAT_DATETIME); }catch (Exception e) { // do something. } } }

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

[06.04.2011] Conference Call REG decided that the new DmtData format date-time will be fixed to cover TR dateTime type. The available ("old") info.dmtree.DmtData.FORMAT_DATE and info.dmtree.DmtData.FORMAT_TIME will not be modified, because the changes will be backward incompatible. The extended date-time pattern will be in a short format i.e. without separators like hyphen "-".

My understanding is correct ?

• Steffen is responsible for updating the Javadoc.
• No need to modify TR069ParameterValue.getDmtData() impl (as it is): if (tr069Type.equals(TR069_TYPE_DATETIME)) { if ((format & DmtData.FORMAT_DATETIME) != 0) { try { data = new DmtData(value, DmtData.FORMAT_DATETIME); }catch (Exception e) { // do something. } } } The PA utility classes need a simple update. They should convert TR-069 extended format to DmtData one (see Comment BZ#2). In general, that means the method should remove the hyphens '-'.

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

The PA utility classes need a simple update. They should convert TR-069 extended format to DmtData one (see Comment BZ#2). In general, that means the method should remove the hyphens '-'.

I got it. I had modified RI, which just removes the hyphens before construct DmtData.

[bjhargrave]

Comment author: Kai Hackbarth <k.hackbarth@prosyst.com>

JavaDoc needs to be updated

[bjhargrave]

Comment author: Steffen Druesedow <steffen.druesedow@telekom.de>

updated javadoc as proposed in comment 1, pushed to residential branch