Thanks David. I believe the resolution problems with GetSystemTime() are well known, and that more accurate approaches that this API call now exist on Windows platforms.
My surprise was not whether the result had a resolution of milliseconds or microseconds. Instead it was that MarkLogic XQuery provides a different result on different platforms, personally that is a surprise that I do not like as it *potentially* makes XQuery code less portable. Cheers Adam. From: [email protected] [mailto:[email protected]] On Behalf Of David Lee Sent: 01 August 2014 18:09 To: MarkLogic Developer Discussion Cc: Sahay, Saurabh (RBI-UK); Shan, Thulasee (RBI-UK); [email protected]; Naik, Rajeev (RBI-UK); Rahul Gupta Subject: Re: [MarkLogic Dev General] XQuery difference between windows and linux platforms It comes down to what OS calls are used to get the current time. On windows its GetSystemTime() http://msdn.microsoft.com/en-us/library/windows/desktop/ms724390(v=vs.85).aspx Which only has fields for millisecond http://msdn.microsoft.com/en-us/library/windows/desktop/ms724950(v=vs.85).aspx On linux its gettimeofday() http://linux.die.net/man/2/gettimeofday Which has fields for microseconds. Not at all clear if the accuracy is to microseconds but this affects the rounding. Running on windows I see: fn:current-dateTime() == 2014-08-01T12:59:01.233-04:00 Showing 3 digits fractional seconds On linux I see 2014-08-01T12:51:26.281268-04:00 Showing 6 digits of fractional seconds That makes all the difference when you subtract Windows xs:dayTimeDuration("P16283DT16H59M1.233S") linux xs:dayTimeDuration("P16283DT16H51M26.281268S") Now its still a dayTimeDuration / but that's defined in terms of xs:decimal - which works. http://www.w3.org/TR/xpath-functions/#func-numeric-divide if you change the return type to xs:decimal it works fine on both declare function local:unix-timestamp() as xs:decimal { (fn:current-dateTime() - xs:dateTime("1970-01-01T00:00:00-00:00")) div xs:dayTimeDuration('PT0.001S') }; Linux: 1406912512976.113 Since XQuery fn:current-dateTime() is imdopedent, having a value more precise then a second is not usually useful, so I suggest a cast, either in the function or outside. e.g. declare function local:unix-timestamp() as xs:unsignedLong { ((fn:current-dateTime() - xs:dateTime("1970-01-01T00:00:00-00:00")) div xs:dayTimeDuration('PT0.001S')) cast as xs:unsignedLong }; Or local:unix-timestamp() cast as xs:unsignedLong From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Retter, Adam (RBI-UK) Sent: Friday, August 01, 2014 12:00 PM To: MarkLogic Developer Discussion Cc: Sahay, Saurabh (RBI-UK); Shan, Thulasee (RBI-UK); Naik, Rajeev (RBI-UK); Rahul Gupta; [email protected]<mailto:[email protected]> Subject: [MarkLogic Dev General] XQuery difference betwee windows and linux platforms I have accidentally found that this query works different on Windows and Linux platforms - declare function local:unix-timestamp() as xs:unsignedLong { (fn:current-dateTime() - xs:dateTime("1970-01-01T00:00:00-00:00")) div xs:dayTimeDuration('PT0.001S') }; The expression (fn:current-dateTime() - xs:dateTime("1970-01-01T00:00:00-00:00")) div xs:dayTimeDuration('PT0.001S') returns an xs:decimal which is correct. However it seems with MarkLogic on Windows platforms this will always return a natural number, and so the implicit cast demanded by the function signature to an xs:unsignedLong will always work. However on Linux, the same expression always returns a decimal number, as such the implicit cast fails (as should be expected). Now obviously I can fix this by using fn:floor around my expression to ensure I get a natural number which can then implicitly be cast to an xs:unsignedLong. However, I do not understand why XQuery here in MarkLogic behaves differently on Windows and Linux platforms?!? Are there other cases that I need to watch out for? Thanks Adam. DISCLAIMER This message is intended only for the use of the person(s) ("Intended Recipient") to whom it is addressed. It may contain information, which is privileged and confidential. Accordingly any dissemination, distribution, copying or other use of this message or any of its content by any person other than the Intended Recipient may constitute a breach of civil or criminal law and is strictly prohibited. If you are not the Intended Recipient, please contact the sender as soon as possible. Reed Business Information Limited. Registered Office: Quadrant House, The Quadrant, Sutton, Surrey, SM2 5AS, UK. Registered in England under Company No. 151537
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
