I had done this before using an SQLite formula, but can't find the original formula I used. Basically I am getting data returned as ticks which are nanoseconds since Jan 1, 1601 [a Gregorian Calendar thing, maybe]. Anyway, the simple script below doesn't fail, just doesn't return correct date. I tried to work around with HugeMath Extender but that got me more tick'd off :( . Anyway, await the slings and arrows for this bad code: [CLR TimeSpan would work but not ready for WB Primetime, and in PS a simple Get-Date 635241312000000000 w
works.
ticks = 635241312000000000 ;should be January 1, 2014 12:00:00 AM
ticks = (ticks/10000000)
Message("",ticks)
TickBase="1601:01:01:00:00:00"
AddTime = "0000:00:00:00:00:%ticks%"
Later=TimeAdd(TickBase, AddTime)
Message(TickBase, Later)
; Ticts are the granularity of the Windows OS system time
; and a tick is 100 nanoseconds.
ticks = ObjectType('i8',635241312000000000)
Date1 = ObjectClrNew("System.DateTime",ticks)
strDate = Date1.ToString()
exit
As it turns out your question did lead to the discovery of an issue with ObjectClrNew's handling of 64-bit integers. That is why the example I posted had to use the ObjectType function. (The example works just fine because of the call to ObjectType.)
Thanks. Nice to circle back to the CLR; 1601 was not a good year. Between that base date, the Excel base date [1900 or 1899] and the Unix base of 1970 - I'm reminded of the Chicago song 'does anyone really know what time it is?' ???
Quote from: stanl on October 22, 2021, 03:02:48 AM1601 was not a good year.
I'm not so sure about that. The premiere of Shakespeare's
Hamlet occurred that year. ;)
Quote from: jmburton2001 on October 22, 2021, 08:36:12 AM
I'm not so sure about that. The premiere of Shakespeare's Hamlet occurred that year. ;)
Sure. Look how that ended. 8)
[EDIT]: Darn! I thought someone would come back with "does anybody really care" - [Chicago reference]
For the non-bardolators among us:
"There is nothing either good or bad, but thinking makes it so."
- William Shakespeare, Hamlet