Date Formate when using ds.WriteXml

  • Thread starter Thread starter Robert Scarborough
  • Start date Start date
R

Robert Scarborough

I have a Table in a Typed Dataset which contains a Date field called
EventDate.
I've ensured that the field is defined as Date as opposed to DateTime in the
Typed Dataset.

When I generate an xml file from an instance of this typed dataset using the
ds.WriteXml method, all the dates come out formatted as follows:

<EventDate>2004-01-26T00:00:00.0000000-05:00</EventDate>

which is the DateTime datatype of the W3C XML Schema Part 2: Datatypes

I want the dates to come out as

<EventDate>2004-01-26</EventDate>

which is the Date datatype of the W3C XML Schema Part 2: Datatypes

How to I force the WriteXml method to output dates as the Date datatype as
opposed to the DateTime datatype?
 
Robert Scarborough said:
I have a Table in a Typed Dataset which contains a Date field called
EventDate. I've ensured that the field is defined as Date as opposed
to DateTime in the Typed Dataset. : :
<EventDate>2004-01-26T00:00:00.0000000-05:00</EventDate>

which is the DateTime datatype of the W3C XML Schema Part 2: Datatypes

I want the dates to come out as

<EventDate>2004-01-26</EventDate>
Click to expand...

I think you'll need to use an XmlTextWriter subclass to intercept the output
of WriteXml( ) when it's writing these dates. Here's a XmlTextWriter to get
you started,

- - - DsDateFilterXmlTextWriter.cs
// . . .
public class DsDateFilterXmlTextWriter : XmlTextWriter
{
private string watchElement;
private bool onWatch;

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

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( "yyyy-MM-dd");
}
catch ( FormatException )
{
;
}
onWatch = false;
}
base.WriteString( text);
}
}
// . . .
dataSet1.WriteXml( new DsDateFilterXmlTextWriter( Console.Out, "EventDate") );
// . . .
- - -

The DataSet represents the value with the time zone to ensure it's unambiguous
what date it represents (for instance, at 11 p.m. in Chicago, the date you've
given is January 25, but in London, England, it's January 26).


Derek Harmon
 
Thanks for the very robust reply.

I understand that the DateTime format contains the time zone information.
But there are many situations where the time zone information isn't
appropriate and just the simple Date is necessary. The W3C recognizes this
by the fact that they also define a simple Date-only format (Namely "Date")
as an alternative to DateTime.

I wish Microsoft would have given us some kind of property to set to control
whether dates are spit out as DateTime or Date rather than forcing DateTime.
In our particular application, we need to send to customers around the
world, lists of dates indicating when bank holidays occur around the world.
It doesn't make sense to have my particular time zone information (Eastern
Standard) included in a list of bank holidays for Tokyo.

The problem with your suggestion for my particular case is that I also want
to be able to use the ds.WriteXmlSchema method to send my clients a schema
which matches my data. So I would also have to do some fiddling with that
to match the changes you've suggested. I suppose I could just create a new
string field in my Datatable to contain the string value of the date, but
then the schema would define that field as a String rather that a Date.
Perhaps your suggestion is my only option and I'll have to also have code to
modify the schema and code to make sure everything is in synch - yecht.

I hope I don't sound like I'm complaining to you. I just hope someone from
Microsoft is watching.

Thanks again for your help.


Bob Scarborough
 
Thanks for the info. It makes for interesting reading.

On the one hand, its nice to see that I'm not alone in my problems.

On the other hand, its not nice to see that Microsoft doesn't have a
solution.

Bob Scarborough
 
Back
Top