I’m trying to write a simple profiler to measure how long operations take and the simplest way that I can see of doing this with Sugar is something like:
let startTicks = DateTime.Now.Ticks ...execute operation... let endTicks = DateTime.Now.Ticks let msTaken = endTime.Subtract(startTime).Milliseconds
However when I try to use DateTime.Now.Ticks I’m shown a compile time error that Timespan doesn’t exist, unless I’m mistaken it should be TimeSpan?
I’d make the change myself to test it but my Oxygene licence has expired, I do see a number of occurrences of Timespan in the DateTime.pas file.
I’ve fixed the case mismatches in Sugar itself, but it’s definitely a compiler bug that these bubble up into your Swift code, so that’s something we’ll need to address separately. Mean time, if toys rebuild latest Sugar from github (no Oxygene license needed to do that), the error should go away.
I can’t say. It seems to be a bug in the compiler with how inlined code written in Oxygene (which is case insensitive) gets processed when used from Swift (which is case sensitive).
macbookproloreto:swift-promise-example admin$ date -r1453824641
Mar 26 Gen 2016 17:10:41 CET
The issue here is that now it’s actually GMT+1 and so
macbookproloreto:swift-promise-example admin$ date +%s
1453821311
macbookproloreto:swift-promise-example admin$ date -r1453821311
Mar 26 Gen 2016 16:15:11 CET
Odd, i just checked and found none. all have the proper case now. Sure the have the latest revision checked out?
hmm, maybe you need to use DateTime.UtcNow? I’m not sure how this all is supposed to work, but we just pass the core system APIs thru. What platform are you on, Cocoa? Does the same give different results on .NET or Java?
Hmm, looks like we dint expose this yet. this seems tricky, on Cocoa, NSDateTimes are always time-zone agnostic (ie NSDate.dateis UTC, in essence), it’s during printing and conversion that it gets adjusted to a local timezone. By contrast, .NET exposes DateTime.Now (local) and DateTime.UtcNow (UTC) so apparently each time instance carries a timezone with it… this complicates things :(.
That said, no idea ion that is your issue, it sounds like its shouldn’t be, if you are on Cocoa. But i known very little about how UNIX epochs work, excalty.
/**
* UTC ISO Date to String
*/
-(NSString*)formatUTCISODate:(NSDate*)date {
NSString *stringDate = [utcISODateFormatter stringFromDate:date];
return stringDate;
}