XYplorer Beta Club

SkyFrontier wrote:Hm.
Errrrr...
Han...

I still can't see a way to convert those calculations into XY scripting, specially as (per my own initial observations and attempts) the farthest we could go is (like http://www.wolframalpha.com/input/?i=13 ... 0+*+100+ns clearly says) is a full amalgam of nanoseconds instead of a nice "2013-07-02 18:37" user readable format (not to mention the total lack of a clue on how to convert such date back into nanosecs!).

-and don't you dare to tell me that such conversion is 'pretty straightforward', right?


Strangely, that tune also reminds me Danny Boyle's Sunshine OST, a movie that was certainly made to be a full sensory experience.

Thanks for helping! Have a good nite.

Here it is.

0. I take for granted thatcorresponds to 2013-06-13 13:36 (ISO 8601)

1. So I pick the left part of the number and convert to binary ( http://www.wolframalpha.com/input/?i=30304315+to+bin ), and I get 2. I do the same with the right part ( http://www.wolframalpha.com/input/?i=327317760+to+bin ), obtainingBe careful here! We need eventually a 64bit number, made up by chaining two 32bit numbers. This second one needs thus proper left padding 3. Now we can join the two binary numbers together 4. Conversion to decimal gives us ( http://www.wolframalpha.com/input/?i=00 ... 0100000000 ) 5. ...which is the number of 100-ns intervals from the "time zero" in NTFS. In "human" times it equates to ( http://www.wolframalpha.com/input/?i=16 ... 0+*+100+ns ) ...



Don, what's wrong in these calculations?

Are you sure that wolframalpha is bug-free?

Nothing is sure in life...
But, is the underlying concept correct? And also, why the low part of filetime is a signed integer?

Marco wrote:Nothing is sure in life...
But, is the underlying concept correct? And also, why the low part of filetime is a signed integer?

The sign is just a matter of interpretation of the underlying bytes. It is irrelevant here.

Ok, some more testing.
gives 13015604160 seconds
The math above returns 13015604218 seconds. There's a difference of 58 seconds that maybe it's due to leap seconds or who knows what.
Definitely a WAlpha bug then.

Guys,

thanks for the answers and Don, specially, for the implementation.
-but I can't switch back into "lo, hi" values, yet!

(and as a side note just discovered my text-to-binary back-and-forth scripts are broken either!)


Some tests though reveal there's something going wrong, here...

*all* of these gives the same result!
30308178,-1661513984, "2010-01-02 03:00"; // 2/7/2013 18:33:14
30308178,-1661013984, "2011-11-30 03:00"; // 2/7/2013 18:33:14
30308178,-1660313984, "1999-06-30 15:30"; // 2/7/2013 18:33:14
30308178,-1659813984, "2000-09-15 21:50"; // 2/7/2013 18:33:14
30308179,903686016, "2013-07-02 18:37"; // 2/7/2013 18:33:14

...but those two are ALMOST ok!
30304324,-922355200, "2013-06-13 13:46"; // 13/6/2013 14:46:28 - wrong for '14h'
30304315,327317760,"2013-06-13 13:36"; // 13/6/2013 13:36:58
_____________________

Hey, flag 2 is cool!

echo formatdate("13-6-2013 11:46:28",,,,2); // 13/6/2013 11:46:28

copytext (formatdate("2011-11-30 03:00",,,,2)); // 30/11/2011 03:00:00

Are you talking about SC formatdate? Nore that the flag is only for filetimes: