On Thu, 10 Mar 2011 09:43:11 +0100, Karin Bredenberg wrote
> I dont think its a bug. It's not using the standard and as simple as
What your C# lib does is perfectly fine, just as your mail program writing
out dates as "Thu, 10 Mar 2011 09:43:11 +0100" in the date field of the mail
header.. its just not ISO 8601..
> So my point with saying C# gives you <date>2011-02-28 15:34:08</date>
Its relatively straightfoward to write code to get an ISO 8601 date in
nearly every computer language from Algol to ... including C#
C# is especially easy since you can use DateTime formating:
> is that not all programmers are aware of the fact that this is not
> according to standard and wont validate if the format of the XML-element
> is a datetime.
> Writing an XSLT fix can be done but its better to construct the
> datetime on your own when you make the value in C# by using date and
> time and combine them with the letter "T".
> So some education is perhaps also needed.
> No point in discussing this any more, I just wanted to point out that
> this is out here.
> >>> [UTF-8?]SaaÅ¡ha Metsärantala <[log in to unmask]> 2011-03-10 01:34 >>>
> > > it ends uplike this:
> > > <date>2011-02-28 15:34:08</date>
> > > so there are no T present.
> > How some programming language handles
> > these details is irrelevant. We should
> > stick to ISO 8601.
> I also consider that it is good to try to stick to ISO 8601. If some
> specific non-standard-compliant software has a bug and forgets the T in
> its outputs, it should be quite easy to write an XSLT to fix that
> afterwards. Maybe someone on the list already has such an XSLT to be
> in different contexts.
> > * #206 Calendar week e.g. 1985W15 (week 15 of 1985)
> I would suggest to add a little note about the circumstances when it
> be encouraged to write 1985W15 and when it would be encouraged to write
> 1985-04-08/P7D instead.
> > so slap me upside the head
> I have absolutely no reason to use any kind of violence! On the
> it seems that we could agree about the fact that there may be no
> to have a feature whose usefulness is (as of today) not obvious and
> definition is built on a coarse approximation.
> My message was that I consider it is good practice to try to be aware
> the limitations of our specs, even when those limitations may seem
> distant. Awareness helps to write a better documentation and good
> documentation today will help for a better future awareness of these
> limitations, which helps us to avoid inconsistencies in our (future)
> Different (small) shortcommings and inconsistencies which, one by one,
> seem negligible can sometimes be far less negligible if they happen to
> occur together. Maybe you wonder whether I have an example for that in
> context of this spec. But: If I had an example, it would be a use
Edward C. Zimmermann, NONMONOTONIC LAB