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
> that.
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:
yyyy-MM-ddTHH:mm:ssZ
see
http://msdn.microsoft.com/en-us/library/8kb3ddd4.aspx
> 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.
>
> Karin
>
> >>> [UTF-8?]SaaÅ¡ha Metsärantala <[log in to unmask]> 2011-03-10 01:34 >>>
> Hello!
>
> > > 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
> used
> 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
> would
> 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
> contrary,
> it seems that we could agree about the fact that there may be no
> reasons
> to have a feature whose usefulness is (as of today) not obvious and
> which
> definition is built on a coarse approximation.
>
> My message was that I consider it is good practice to try to be aware
> of
> 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)
> specs.
>
> Different (small) shortcommings and inconsistencies which, one by one,
> may
> 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
> the
> context of this spec. But: If I had an example, it would be a use
> case.
>
> Regards!
>
> [UTF-8?]Saašha,
--
Edward C. Zimmermann, NONMONOTONIC LAB
http://www.nonmonotonic.net
Umsatz-St-ID: DE130492967
|