Since the almighty webdesigner (all kneel!) wants the date to be displayed like this: 08/10/12.
I can make the date display in nearly any other way than with the '/'s, i.e. 08.10.12, but when I try the above pattern it just outputs it the standard way: 08-10-12.
Any reason for this? :-) Or even better, any way to make it render the date with this format other than creating your own extension for it?
That sounds like a bug to me - I don't know the internals of the FormatDateTime() method, but unless it's not possible in "plain" C# to use that spedific format string either (does the slashes need escaping maybe?) I'd go file a bug ASAP :-)
To get you through the night though, here's a couple of ways:
1. Use FormatDateTime() to get 08.10.12 and then translate the dots to slashes:
Hmm, I'll have to dig into the library method then. Mayhaps it's missing the CultureInfo.. just guessing here. It should be perfectly fine to do in C#.
I went with your first suggestions for the time being, which works like it should! Thanks :-)
Alright, had a look at the method and it seems the CultureInfo is not set when calling the ToString() method. Not 100% sure this is what causes the problem, though as I haven't tested it.
The culture info would actually be quite a good guess, I think... as far as I know, the transformation usually inherits the current locale (some of the internal XSLT/XPath functions actually use that, e.g. the <xsl:sort> will sort correct between æ, ø & å when the macro runs with danish locale).
What happens when turning things over to extension methods I don't know - but I trust you'll find out :-)
Here's a bonus template (you will want to use them at som point, you know :-) to make sure that when (eventually) the client finally settles on a different format, you don't need to search & replace a lot of places:
<!-- Use for intrinsic attributes: -->
<xsl:apply-templates select="$currentPage/@createDate" mode="date" />
<!-- Or custom properties: -->
<xsl:apply-templates select="$currentPage/eventStartDate" mode="date" />
<!-- Template for date output -->
<xsl:template match="* | @*" mode="date">
<xsl:param name="format" select="'dd.MM.yy'" /><!-- Default format -->
<xsl:value-of select="translate(umbraco.library:FormatDateTime(., $format), '.', '/')" />
</xsl:template>
- and then I read through this one - which clearly states the "/" character as "The date separator." - which means it will be replaced with whatever is specified in the culture for the particular language...
There's also an escape character - tada! "\" - will this work?
I think it's the same when you turn to extensions :-) C# will inherit the current locale aswell unless you specify something else. Since I'm running on localhost and my system is in english, I guess that's why.
Thanks for the template! I'm actually getting used to use templates after you've swung the whip at my back several times ;-) It starts to make sense, after all.
Ahhh, I didn't see the possibility of escaping the format string. D'oh !! It works perfectly :-)
Not sure if I should delete my issue now then. After all, it might be convenient to be able to pass in the culture as a parameter to the extension, no?
Formatting the create date
Hi all,
I have once again ventured into the ever dark and gloomy cave of XSLT and have got some problems with formatting the create date of a node.
What I have in my XSLT is this:
Since the almighty webdesigner (all kneel!) wants the date to be displayed like this: 08/10/12.
I can make the date display in nearly any other way than with the '/'s, i.e. 08.10.12, but when I try the above pattern it just outputs it the standard way: 08-10-12.
Any reason for this? :-) Or even better, any way to make it render the date with this format other than creating your own extension for it?
Thanks a lot in advance.
All the best,
Bo
Hi Bo,
That sounds like a bug to me - I don't know the internals of the FormatDateTime() method, but unless it's not possible in "plain" C# to use that spedific format string either (does the slashes need escaping maybe?) I'd go file a bug ASAP :-)
To get you through the night though, here's a couple of ways:
1. Use FormatDateTime() to get 08.10.12 and then translate the dots to slashes:
2. Do it using simple extractions and concat() -
/Chriztian
Hi Chriztian,
Thanks for your quick answer as always!
Hmm, I'll have to dig into the library method then. Mayhaps it's missing the CultureInfo.. just guessing here. It should be perfectly fine to do in C#.
I went with your first suggestions for the time being, which works like it should! Thanks :-)
Code:
I'll file it as bug when I get my hands into the source to check what happens.
Thanks again.
- Bo
Alright, had a look at the method and it seems the CultureInfo is not set when calling the ToString() method. Not 100% sure this is what causes the problem, though as I haven't tested it.
Posted it as an issue on the tracker: http://issues.umbraco.org/issue/U4-1000
All the best,
Bo
Great :-)
The culture info would actually be quite a good guess, I think... as far as I know, the transformation usually inherits the current locale (some of the internal XSLT/XPath functions actually use that, e.g. the <xsl:sort> will sort correct between æ, ø & å when the macro runs with danish locale).
What happens when turning things over to extension methods I don't know - but I trust you'll find out :-)
Here's a bonus template (you will want to use them at som point, you know :-) to make sure that when (eventually) the client finally settles on a different format, you don't need to search & replace a lot of places:
/Chriztian
- and then I read through this one - which clearly states the "/" character as "The date separator." - which means it will be replaced with whatever is specified in the culture for the particular language...
There's also an escape character - tada! "\" - will this work?
/Chriztian
Chriztian,
I think it's the same when you turn to extensions :-) C# will inherit the current locale aswell unless you specify something else. Since I'm running on localhost and my system is in english, I guess that's why.
Thanks for the template! I'm actually getting used to use templates after you've swung the whip at my back several times ;-) It starts to make sense, after all.
Ahhh, I didn't see the possibility of escaping the format string. D'oh !! It works perfectly :-)
Not sure if I should delete my issue now then. After all, it might be convenient to be able to pass in the culture as a parameter to the extension, no?
I say let it stay on there, and let the comments/votes decide on how/when/where to implement that.
Great topic - I learned some nitty gritty format date stuff (which every Perl & PHP developer probably knew by heart at birth, but ... :-)
/Chriztian
is working on a reply...
This forum is in read-only mode while we transition to the new forum.
You can continue this topic on the new forum by tapping the "Continue discussion" link below.