Got it. :) Don't know why but SharePoint was ignoring the LCID and custom stringFormat in the FormatDateTime function. Finally got around this by using:
*RegisterBy* = number(ddwrt:FormatDateTime(string(@Register_x0020_By),*3081* ,'*yyyyddMM*')) * * And Today comes through in ISO format as expected, so I just grabbed the sub-string. * * *Today* = number(translate(substring-before($Today,'T'),'-',''))"> Hope this helps someone else! End result: [image: Inline images 1] On 9 April 2013 14:19, Web Admin <[email protected]> wrote: > OK. Officially giving up now. I don't know if it's a caching issue or > fluctuating date values. > > Now SPD gives correct result while browser fails. > > > On 9 April 2013 13:43, Web Admin <[email protected]> wrote: > >> This is driving me nuts! [?] >> >> I reworked the date formats and output precise numeric values and it >> failed. >> >> I then reverted to my original calculation and it's working again.....on >> ONE form! >> >> What tha...?!?!! >> >> On 9 April 2013 12:54, Specker, Caroline < >> [email protected]> wrote: >> >>> I had a similar date issue on a SP2010 farm with SP1. Installing the >>> latest CU fixed it.**** >>> >>> ** ** >>> >>> *From:* [email protected] [mailto:[email protected]] *On >>> Behalf Of *Web Admin >>> *Sent:* Tuesday, 9 April 2013 12:45 PM >>> *To:* ozMOSS >>> *Subject:* Re: [SP2013] DVWP Conditional Formatting with XSLT**** >>> >>> ** ** >>> >>> OK. So I have done more testing and can confirm it's a SharePoint date >>> issue.**** >>> >>> ** ** >>> >>> I know that the raw output for Today is coming through as *2013-04-09* >>> T12:26:21Z.**** >>> >>> ** ** >>> >>> When converted ticks this is displaying as 635138496000000000 which is >>> actually *2013-09-04*.**** >>> >>> ** ** >>> >>> If I set the *RegisterBy *date to *04-09-2013* I get the result I >>> expected. It looks like a US date format issue, although both the server >>> and SharePoint site are set to Australia and dd/mm/yyyy date format.**** >>> >>> ** ** >>> >>> Anyone know an easy fix for this? :)**** >>> >>> On 9 April 2013 12:17, Web Admin <[email protected]> wrote:* >>> *** >>> >>> Hi all,**** >>> >>> ** ** >>> >>> A few weeks back I created a site customisation that used a variety of >>> Custom List Forms using DVWPs with filtering and conditional formatting. >>> **** >>> >>> ** ** >>> >>> I know these all worked because I vigorously tested them all and also >>> posted here about a few issues I encountered.**** >>> >>> ** ** >>> >>> On re-visiting the site today I noticed that the conditional formatting >>> I'd applied to certain fields was no longer working. These were pretty >>> simple date comparisons against Today.**** >>> >>> ** ** >>> >>> I'm using the following calculation:**** >>> >>> ** ** >>> >>> <xsl:when**** >>> >>> test="number(ddwrt:DateTimeTick(ddwrt:GenDisplayName( >>> string(@Register_x0020_By)))) < **** >>> >>> number(ddwrt:DateTimeTick(ddwrt:GenDisplayName(string($Today))))"*** >>> * >>> >>> >** ** >>> >>> ** ** >>> >>> Outputting the value of these to screen gives the following results. For >>> some reason *$Today* is calculated wrongly and is significantly larger >>> than it should be.**** >>> >>> ** ** >>> >>> *RegisterBy* *6/05/2013* 635033952000000000 >>> *Today * *9/04/2013 *635138496000000000**** >>> >>> ** ** >>> >>> Does anyone have ANY idea why this is occurring?**** >>> >>> ** ** >>> >>> Regards,**** >>> >>> ** ** >>> >>> Paul**** >>> >>> ** ** >>> >>> ************************************************************************* >>> The information contained in this e-mail, and any attachments to it, >>> is intended for the use of the addressee and is confidential. If you >>> are not the intended recipient you must not use, disclose, read, >>> forward, copy or retain any of the information. If you received this >>> e-mail in error, please delete it and notify the sender by return >>> e-mail or telephone. >>> >>> The Commonwealth does not warrant that any attachments are free >>> from viruses or any other defects. You assume all liability for any >>> loss, damage or other consequences which may arise from opening >>> or using the attachments. >>> >>> The security of emails transmitted in an unencrypted environment >>> cannot be guaranteed. By forwarding or replying to this email, you >>> acknowledge and accept these risks. >>> ************************************************************************* >>> >>> _______________________________________________ >>> ozmoss mailing list >>> [email protected] >>> http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss >>> >>> >> >
<<image.png>>
<<329.png>>
_______________________________________________ ozmoss mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
