Bug #4087
Regex in DateTimeMarshaller allowing invalid xsd dateTime
100%
Description
The XSD spec should be followed in the DateTimeMarshaller class
The current regular expression for DateTime TimeZone pattern is (?:(?:[\+\-]\d\d:?\d\d)|Z)
But the spec states that the ':' is not optional
http://www.w3.org/TR/xmlschema-2/#dateTime
(2013-10-14 18:42:06) robert: The lexical representation of a timezone is a string of the form: (('+' | '-') hh ':' mm) | 'Z'
Associated revisions
refs #4087
Regex in DateTimeMarshaller allowing invalid xsd dateTime
refs #4087
Regex in DateTimeMarshaller allowing invalid xsd dateTime
refs #4087
Regex in DateTimeMarshaller allowing invalid xsd dateTime
refs #4087
Regex in DateTimeMarshaller allowing invalid xsd dateTime
History
#1 Updated by Robert Waltz about 11 years ago
- Target version changed from 2013.42-Block.5.4 to 2013.44-Block.6.1
- Due date changed from 2013-10-26 to 2013-11-09
#2 Updated by Robert Waltz almost 11 years ago
- Milestone changed from CCI-1.2 to CCI-1.3
- Due date changed from 2013-11-09 to 2014-02-01
- Target version changed from 2013.44-Block.6.1 to 2014.4-Block.1.2
#3 Updated by Robert Waltz over 10 years ago
- Status changed from In Progress to Testing
#4 Updated by Robert Waltz over 10 years ago
- Due date changed from 2014-02-01 to 2014-03-29
- Target version changed from 2014.4-Block.1.2 to 2014.12-Block.2.2
#5 Updated by Rob Nahf over 10 years ago
While looking into whether I could help out on closing out this ticket, I noticed that there seem to be standardized solutions out there for what we are doing (via xmlbeans.apache.org.XMLDateTime and XmlDateTime.Factory).
So the question is whether we can reduce our maintenance load and be more inline with what others are doing by adopting those solutions. Have we looked into these solutions before?
#6 Updated by Rob Nahf over 10 years ago
- Target version changed from 2014.12-Block.2.2 to 2014.14-Block.2.3
- Due date changed from 2014-03-29 to 2014-04-12
#7 Updated by Chris Jones over 10 years ago
- Milestone changed from CCI-1.3 to CCI-1.2
After sprint planning discussions, we decided to include this into the CCI 1.2.6 release.
#8 Updated by Robert Waltz over 10 years ago
- Status changed from Testing to Closed
#9 Updated by Skye Roseboom about 10 years ago
- Due date changed from 2014-04-12 to 2014-09-24
- Target version changed from 2014.14-Block.2.3 to CCI-1.5.0
#10 Updated by Robert Waltz about 10 years ago
- Status changed from Closed to In Progress
#11 Updated by Robert Waltz about 10 years ago
- Status changed from In Progress to Testing
#12 Updated by Robert Waltz about 10 years ago
- Due date changed from 2014-09-24 to 2014-10-02
- Target version changed from CCI-1.5.0 to CCI-1.4.1
#13 Updated by Robert Waltz about 10 years ago
- Milestone changed from CCI-1.2 to CCI-1.4
#14 Updated by Rob Nahf about 10 years ago
- Due date changed from 2014-10-02 to 2014-10-17
#15 Updated by Rob Nahf about 10 years ago
- Product Version changed from 1.1.4 to 1.2.0
v1.1.4 of d1_common_java was not released, so researched svn, and determined this fix was released in v1.2.0.
#16 Updated by Robert Waltz about 10 years ago
- Target version changed from CCI-1.4.1 to CCI-1.5.0
- Due date changed from 2014-10-17 to 2014-10-07
#17 Updated by Rob Nahf about 10 years ago
- Due date changed from 2014-10-07 to 2014-10-20
#18 Updated by Rob Nahf about 10 years ago
- Due date changed from 2014-10-20 to 2014-10-27
Unless I'm missing something, this seems to be already in a tagged product release. D1_COMMON_JAVA_v1.2.0, which is already incorporated into tags/D1_CN_COMMON_v1.2.0, referencing v1.2.1 of d1_common_java. I assume that the presence of this d1_cn_common tag means that it is in production?
#19 Updated by Robert Waltz almost 10 years ago
- Status changed from Testing to Closed
- Due date changed from 2014-10-27 to 2015-01-06
