OT - convert notations

[Marco]

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 that

Code: Select all

30304315·327317760

corresponds 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

Code: Select all

1110011100110100000111011

2. I do the same with the right part ( http://www.wolframalpha.com/input/?i=327317760+to+bin ), obtaining

Code: Select all

10011100000100111100100000000

Be careful here! We need eventually a 64bit number, made up by chaining two 32bit numbers. This second one needs thus proper left padding

Code: Select all

00010011100000100111100100000000

3. Now we can join the two binary numbers together

Code: Select all

111001110011010000011101100010011100000100111100100000000

4. Conversion to decimal gives us ( http://www.wolframalpha.com/input/?i=00 ... 0100000000 )

Code: Select all

130156042180000000

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 )

Code: Select all

Monday, January 1, 1601 (Gregorian calendar)+13015604218000000000 ns  (nanoseconds)
=
Saturday, September 21, 2013

...



Don, what's wrong in these calculations?

[admin]

Are you sure that wolframalpha is bug-free?

[Marco]

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

[admin]

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.

[Marco]

Ok, some more testing.

Code: Select all

text datediff("1601-01-01","2013-06-13 13:36", "s");

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.

[SkyFrontier]

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

[admin]

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

Code: Select all

     flags:  1 = Date is FileTime ("high,low").
             2 = Localize FileTime (UTC to local time).