System.FormatException: String was not recognized as a valid DateTime
Occurs in a 4.0.3 (Assembly version: 1.0.3625.27276) installation. My xslt logic is to compare a date property with today and I'm using umbraco.library:DateGreaterThanToday
The error comes from the xslt editor parser and seems to be an old horse. I see several threads about this on the forum. What I can't fathom is why this code produces exact same format:
The property item is by Date Picker datatype. I've tried all kinds of variations on formatting, in the end of the day it is the date propery that is not comparable because the date format is not recognized. I understand that this may be some kind of culture problem.
I have just tried to play around with the extension on a 4.6.1 install and when I don't use the $currentPage parameter I get the same error as you posted above and I can't imagine that there is something version dependant with the extensions.
As I've stated, if I display the value of the property through an xslt value-of (inside the loop), it seems to have exactly the same format as umbraco.library:CurrentDate(): The value 2010-10-22T00:00:00 displays nicely, while CurrentDate() displays as 2011-01-20T20:21:48.
So why does the function DateGreaterThanToday('date value') accept CurrentDate() and not my date picker property value? Again: They are displayed to me with exact the same format. I'm probably quite dense about something here, but I honestly haven't got a clue. Except I suspect it has something to do with culture conflicts one the server. Maybe.
<ul> <xsl:for-each select="umbraco.library:GetXmlNodeById(4598)/node"> <li> <h4><xsl:value-of select="@nodeName" /></h4> <ul> <xsl:for-each select="node"> <li> <!-- Displaying the 2 dates that are to be compared: --> <xsl:value-of select="umbraco.library:CurrentDate()" /> <xsl:value-of select="node/data[@alias = 'dateFrom']" /><br /> <!-- The compare that works: it's false of course --> <xsl:value-of select="umbraco.library:DateGreaterThanToday(umbraco.library:CurrentDate())" />
<!-- Here's the value that's not accepted by the xslt parser: --> <xsl:value-of select="umbraco.library:DateGreaterThanToday(node/data[@alias = 'dateFrom'])" />
<!-- This is what should be displayed if dateFrom is greater than today --> <xsl:value-of select="umbraco.library:ShortDate(node/data[@alias = 'dateFrom'])" />: <xsl:value-of select="@nodeName" /> </li> </xsl:for-each> </ul> </li> </xsl:for-each> </ul>
</xsl:template>
Result when the offending statement is omitted:
2011-01-20T23:42:58 2010-10-20T00:00:00 false20.10.2010: Atletico Madrid - Rosenborg
The error messag when trying to display the offending statement:
Error occured
System.FormatException: String was not recognized as a valid DateTime. at System.DateTimeParse.Parse(String s, DateTimeFormatInfo dtfi, DateTimeStyles styles) at umbraco.library.DateGreaterThanToday(String firstDate)
I think you've encountered the "almost everything is a set" propblem - when you ask for node/data[@alias = 'dateFrom'] within a template or a for-each, you're asking for a set of all the childnodes of the current (in the template/loop) node's dateFrom properties...
Either you really meant to ask for the property on the current node, or there's at least one of the nodes you're looping that has more than one childnode with a dateFrom property... ?
do you get the error if you're just trying to call the extension on a page, where you can access it using $currentPage/node [@alias = 'dateFrom'] without doing the loopy loop stuff?
(I'm sure Chriztian has some great tricks for you :))
I think maybe Chriztian is on to something... Value-of will automatically bring me the first occurence within a set while the DateGreaterThanToday function will need the exact node to compare with. It's true, most of the child nodes under node id 4598 had several nodes with the property dateFrom...
I really feel dumb now. You guys go to sleep while I sort out this by myself. If I'm still too dense tomorrow morning I'll give you bump ;-)
System.FormatException: String was not recognized as a valid DateTime
Occurs in a 4.0.3 (Assembly version: 1.0.3625.27276) installation.
My xslt logic is to compare a date property with today and I'm using umbraco.library:DateGreaterThanToday
The error comes from the xslt editor parser and seems to be an old horse. I see several threads about this on the forum. What I can't fathom is why this code produces exact same format:
2011-01-20T20:21:48 2010-10-22T00:00:00
and this works fine:
while this produces the error:
The property item is by Date Picker datatype. I've tried all kinds of variations on formatting, in the end of the day it is the date propery that is not comparable because the date format is not recognized. I understand that this may be some kind of culture problem.
Can someone please advice me?
Hi Siw
Don't you miss the $currentPage parameter in you sample?
As I see it it does not make sense to match just the node, or am I missing something? Should'nt it look like this?
<xsl:value-of select="umbraco.library:DateGreaterThanToday($currentPage/node/data[@alias = 'dateFrom'])" />
I have just tried to play around with the extension on a 4.6.1 install and when I don't use the $currentPage parameter I get the same error as you posted above and I can't imagine that there is something version dependant with the extensions.
Looking forward to hear more from you :-)
/Jan
Hi Jan
Glad to hear from you late in the evening :-)
My code snippet is from inside a loop:
As I've stated, if I display the value of the property through an xslt value-of (inside the loop), it seems to have exactly the same format as umbraco.library:CurrentDate(): The value 2010-10-22T00:00:00 displays nicely, while CurrentDate() displays as 2011-01-20T20:21:48.
So why does the function DateGreaterThanToday('date value') accept CurrentDate() and not my date picker property value? Again: They are displayed to me with exact the same format. I'm probably quite dense about something here, but I honestly haven't got a clue. Except I suspect it has something to do with culture conflicts one the server. Maybe.
Siw
Hi Siw
I really should be sleeping but I just can't help it. It's a joy to try and help people out :-)
I'm thinking it'll be easier to move forward if you post the entire code snippet - that way it should also be easier to replicate on a 4.0.3 install.
/Jan
Hi again Jan
Here's the full loop:
Result when the offending statement is omitted:
false20.10.2010: Atletico Madrid - Rosenborg
The error messag when trying to display the offending statement:
Error occured
System.FormatException: String was not recognized as a valid DateTime.
at System.DateTimeParse.Parse(String s, DateTimeFormatInfo dtfi, DateTimeStyles styles)
at umbraco.library.DateGreaterThanToday(String firstDate)
That help?
Something went wrong in my last post. Complete "Result" is:
false20.10.2010: Atletico Madrid - Rosenborg
Hi Siw,
I think you've encountered the "almost everything is a set" propblem - when you ask for node/data[@alias = 'dateFrom'] within a template or a for-each, you're asking for a set of all the childnodes of the current (in the template/loop) node's dateFrom properties...
Either you really meant to ask for the property on the current node, or there's at least one of the nodes you're looping that has more than one childnode with a dateFrom property... ?
/Chriztian
Hi Siw
do you get the error if you're just trying to call the extension on a page, where you can access it using $currentPage/node [@alias = 'dateFrom'] without doing the loopy loop stuff?
(I'm sure Chriztian has some great tricks for you :))
/Jan
Hi again both of you
I think maybe Chriztian is on to something... Value-of will automatically bring me the first occurence within a set while the DateGreaterThanToday function will need the exact node to compare with. It's true, most of the child nodes under node id 4598 had several nodes with the property dateFrom...
I really feel dumb now. You guys go to sleep while I sort out this by myself. If I'm still too dense tomorrow morning I'll give you bump ;-)
Siw
Hi Siw
Did you get this issue solved? :-)
/Jan
Hi Siw
Did you get this issue solved? :-)
/Jan
yes thank you
is working on a reply...