Ticks

Hi,
What is the Ticks property in DateTime doing ?

I did

Log($'{DateTime.UtcNow.Ticks}');

in a toffee and island console apps

2022-07-02 23:12:01.998631-0400 TicksIslandConsoleApplication[64132:20920022] 637924147210009982
2022-07-02 23:13:35.048382-0400 TicksToffeeConsoleApplication[64380:20922836] 637924004150464900

For a minute and a 1/2 difference the values seem to be way off in the Toffee version

Cheers,
John

Hmm, indeed. Thuis seems wring:

    property Ticks: Int64 read
...
      {$ELSEIF TOFFEE}Int64((mapped.timeIntervalSince1970 + NSTimeZone.localTimeZone.secondsFromGMTForDate(mapped)) * TimeSpan.TicksPerSecond) + TicksTill1970

if I drop the +NSTimeZone.localTimeZone.secondsFromGMTForDate(mapped), the value seems to be more close to what I get in Island and .NET, does that one look correct for you too?

ie

      var n := DateTime.UtcNow;
      var x := Int64(((n as NSDate).timeIntervalSince1970 + NSTimeZone.localTimeZone.secondsFromGMTForDate(n)) * TimeSpan.TicksPerSecond) + DateTime.TicksTill1970;
      writeLn($"x {x}"); //  bad

      var y := Int64(((n as NSDate).timeIntervalSince1970) * TimeSpan.TicksPerSecond) + DateTime.TicksTill1970;
      writeLn($"y {y}");  // correct?

If I im building with the external compiler, to test I just need to copy the .a and .fx files to wherever I have my zip distro installed ?

That, or just drag your own copy of the .fx into the project to add a hint path and delete the original .a. from the References folder of your install (the last part because Appleā€™s ld linker is quirky and otherwise still finds the wrong one if youā€™re unlucky)

The toffee ticks constructor compensated for the ticks property.

I think this extra change works

Thanx! in for the next build.

With Toffee

var dateTime := new DateTime(new DateTime(1970,1,1).Ticks);
      Log($'{dateTime}');

Results in

1970-01-01 05:00:00 +0000

(RTL2/DateTime.pas at master Ā· remobjects/RTL2 Ā· GitHub)

Should this code just be ignoring CurrentCalendar and creating one with a GMT timezone instead ?

ie

Mind you there are other places where currentcalendar is used

TBH Iā€™m not sure right now, both with regard to what the expectation should be for its constructor (surely a local time, not UTC?), and what the other platforms doā€¦ Iā€™ll need to review this.

Update: Microsoftā€™s docs say that on .NET this uses the gregorian calendar always (so that part of the fix is probably good), but it doesnā€™t mention time zones :(. Iā€™ll have to test.

Update 2: This seems to indicate .NET, at least, does not use GMT but the current time zone for this constructor. so that part of your fix would be bad:

Island does the same.

I thought that all dates in RTL2 would be utc

This part is fixed and in.

I donā€™t believe soā€¦ Thatā€™s really not possible, as DateTime does just wrap the system types, so nothing prevents you from assigning a non-UTC System.DateTime (which iirc does store an explicit time zone, no) to an RTL2 DateTime reference.

But I agree this probably needs more review for cleanness and consistency, in general.

Thats an island console app isnt it ?

I get

The magic happens here.
7/6/2022 8:42:39 a 0
7/6/2022 12:42:39 a 0
7/6/2022 8:34:00 a 0

Is that because Im in Canada ?

Im referring to the a 0 and not the time :slight_smile:

Above screenshot is .NET. Island gets the same result value-wise (8, 12, 8).

I too get the ā€œa 0ā€ on Island (which oddly you didnā€™t have/mention in your other thread?). Iā€™m not sure where that comes from, but I logged a separate issue (E25984) for that.

it looks like weā€™re in the same time zone ;).

Update: Locale.Current.DateTimeFormat.LongTimePattern shows ā€œh:mm:ss a zā€ for me. So that probably explains it, itā€™s probably a bug in InternalToString or GetNextFormatToken.

It looks like ā€œaā€ isnā€™t handled at all. ā€œzā€ is the offset from GMT, and it seems thatā€™s set wrong/no timezone is provided.

Is there a reason the Island DateTime has utcnow and now but the RTL DateTime only has utcnow ?

To discourage use of non-UTC dates :wink:

ok :slight_smile:

I tried the latest and without using the timezone I get differences between darwin and toffee when using rtl2.

Can you elaborate? You mean with UtcNow?

No the behavior of the constructor

var dateTime := new DateTime(new DateTime(1970,1,1).Ticks);
      Log($'{dateTime}');

I have some code which is doing something like

DateTime.UtcNow - new DateTime(1970,1,1)

It behaves differently in Toffee and Darwin

That is with or without your fix? Iā€™ll check.