dotnet xml: I get DateTimes back from ADO.Net using XPathDocument for formated as
2005-02-25T00:00:00.0000000-00:00
rather than
2005-02-25T00:00:00
which I get back from SQLXML

which means that for EXSLT work on datefields you need you use
substring-before('.0000000'), (which I know will break some time).
I am not sure where the translation occurs, at present I use
XPathDocument xmlDoc = new XPathDocument(new StringReader(ds.GetXml()));
to get the xml.
Is there another way around this?

[quoted text, click to view]

What time zone is that? Greenwich Mean Time? What if that's U.S.
Eastern Standard Time? Then it's really 2005-02-24T19:00:00.
One can't really tell when the timestamp excludes time zone info,
which is why your DataSet is being more specific.

[quoted text, click to view]

Not necessarily, you can use,

substring(@StartDate, 1, 19)

that will always work. The month and day will always have a leading
zero, it will always be 19 characters long, so it isn't susceptible to breakage
when fractions of a second are involved.

[quoted text, click to view]

You could write a trivial stylesheet to transform (what, attributes/child
elements) from your DataSet's XML representation from ADO.NET
DateTime format to the format you want for SQLXML, using the above
substring( ) function to take the first 19 characters and discard the rest.


Derek Harmon

Derek,
Thanks
Looking around it does seem to be related to timezone, which for me is
GMT. Yes substring(date,1,19) will work fine. I more surprised that the
.Net EXSLT failed in this fashion, I expected the translation into
internal Datetime object would work for the xml representation produced
by AD0.Net for MS_SQL.
Still xslt is modular enough that modifying the separate template is
quite simple, though specific to the ADO.NET to XML translation.
So I was wondering whether I could change the way in which the xml was
obtained from the ADO.NET dataset, at present I use getXML().
Regards Jonathan

*** Sent via Developersdex http://www.developersdex.com ***

[quoted text, click to view]

There's no secret switch to set that would make ADO.NET write out an ambiguous
date/time, if that's what you're asking. :-)

WriteXml( ) is considerably more flexible than GetXml( ), though. You'll need
to inject either an XSLT stylesheet to transform the date/times, or an XmlText-
Writer that reformats date/times. In either situation, choosing GetXml( ) over
WriteXml( ) makes that migratory stage more cumbersome than it should be.

For example, suppose you have one column named SalesDate that maps to an
XML element. You could use the following XmlTextWriter to control how the
content of this field gets written,

public class DateFormatXmlTextWriter : XmlTextWriter
{
private string watchElement;
private string dateFmtSpec
private bool onWatch;

public DateFormatXmlTextWriter( TextWriter writer, string watchElement, string dateFormat)
: base( writer)
{
this.watchElement = watchElement;
this.dateFmtSpec = dateFormat;
}

public override void WriteStartElement( string prefix, string localName, string ns) {
base.WriteStartElement( prefix, localName, ns);
if ( 0 == string.Compare( this.watchElement, localName))
onWatch = true;
}

public override void WriteString( string text)
{
if ( onWatch ) {
try {
DateTime dt = DateTime.Parse( text);
text = dt.ToString( this.dateFmtSpec);
} catch ( FormatException ) { ; }
onWatch = false;
}
base.WriteString( text);
}
}

Then you would call WriteXml( ) pass an instance of this specialized XmlTextWriter
wrapped around your System.IO.StringWriter, the name of the element to watch for,
the date/time format to translate into, and XmlWriteMode.IgnoreSchema.

myDataSet1.WriteXml(
new DateFormatXmlTextWriter( myStringWriter, "SalesDate", "yyyy-MM-ddTHH:mm:ss"),
XmlWriteMode.IgnoreSchema
);

If you're calling GetXml( ) you just won't have this kind of flexibility.


Derek Harmon

thanks Derek, that does work nicely. I guess you could use an attached
schema to determine the datatype of a particular elementname. That may
be could solution for the present time.
Regards Jonathan

*** Sent via Developersdex http://www.developersdex.com ***