Werner,
No prob, glad you were able to use it.
As far as whether you guys should include milliseconds in dateTimes you produce, I'd think about how clients will use the timestamps and if the added precision of milliseconds would ever be valuable to them. If so, I'd include the milliseconds. If not, I think you could go either way.
Regards, Ian
Werner Dittmann wrote:
Ian, all,
thanks for the code. I modified it a bit and put it into our source tree.
Before I really start to use it to create timestamps in the current implementation
I like to ask if the use of timestamps that include milliseconds would pose any
interop problems in current deployments.
Receiving timestamps in both formats is not a problem (thanks to Ian's code).
I would not like to support new timestamps and old ones (without milliseconds)
in parallel during creation of timestamps. This would require yet another
configuration/deployment parameter - and we already have quite a lot of it.
Any thoughts to use the new timestamp format? Comments are highly appreciated.
TIA.
Regards, Werner
Ian Springer schrieb:
Hi,
In case its of interest to anyone, a while back I wrote a Java DateFormat for formatting/parsing xsd:dateTime's. The parse() method was snarfed from an Axis utility method with better error reporting added. It's pretty robust. The format() method uses: new SimpleDateFormat( "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'" ).parse( date ). Source file and test case attached.
Cheers, Ian
Dittmann Werner wrote:
Javier,
WSS4J uses the following format to parse the times:
SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'")
thus we don't parse milliseconds.
Regards, Werner
-----Urspr�ngliche Nachricht-----
Von: Davanum Srinivas [mailto:[EMAIL PROTECTED] Gesendet: Montag, 25. April 2005 23:36
An: Javier Delgadillo
Cc: [email protected]
Betreff: Re: Created Element
Javier,
don't remember running into any vendor who uses milliseconds...all
that the spec (http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-
message-security-1.0.pdf) says is:
The <wsu:Timestamp> element provides a mechanism for expressing the creation and expiration times of the security semantics in a message. All times MUST be in UTC format as specified by the XML Schema type (dateTime). It should be 1300 noted that times support time precision as defined in the XML Schema specification.
it's an interop thing....
thanks, dims
On 4/25/05, Javier Delgadillo <[EMAIL PROTECTED]> wrote:
All, We were doing some inter-operability tests with webMethods Glue. They
produce the following timestamp: <wsse:Created>2005-04-15T00:47:01.792Z</wsse:Created> webMethods has stated they have some versions in QA that will fix the prefix
and correctly mark it as wsu. My question is about the milliseconds in the
actual timestamp. Even after fixing the prefix, the wss4j libraries throw
an exception trying to parse the actual timestamp. I haven't been able to validate whether or not the milliseconds are allowed
here. Has anyone else run into this? How can I make wss4j parse the timestamp
correctly, assuming the milliseconds are valid?
--- Javier Delgadillo
ESRI Internet Solutions Division
(909) 793-2853 x1068
http://arcweb.esri.com/sc/index.html
