You've got two big hints in the work you've already done: an actual date, and the code time_t. Time_t is a Unix thing. Lets try a tool like epoch converter, and push the date you know into it:
the red number is what we want
Hey! that number also appears in your data inspector! It is an int 32! That means we can load your data like this:
za = Open( "z:/123.zip", zip );
blob = za << read( "123.dat", Format( blob ) );
dates = Blob To Matrix( blob, "int", 4, "little", 14 )[0, 1];
dates += 1jan1970;
For( i = 1, i <= 4, i += 1,
Show( i, As Date( dates[i] ) )
);
i = 1;
As Date(dates[i]) = 20Jan2023:06:56:00;
i = 2;
As Date(dates[i]) = 20Jan2023:06:57:00;
i = 3;
As Date(dates[i]) = 20Jan2023:06:58:00;
i = 4;
As Date(dates[i]) = 20Jan2023:07:00:00;
The Unix epoch begins on 1Jan1970, which is 0. The JMP epoch begins on 1Jan1904, which is 0. Adding JMP's 1Jan1970 value to a Unix date converts the Unix date to a JMP date.
The blob to matrix call makes 14 4-byte numbers per row; the subscript [0,1] means 0: keep all 4 rows and 1: keep the first element on each row.
While you are playing with the epoch converter, try some dates in 2038. 2038 is the year of the next two Y2K-like events. Yes, there are two issues in one year. The first one is the Epochalypse at 03:14:07 UTC on 19 January 2038. The second one is the third GPS week roll over, which will probably go unnoticed. The third rollover will occur between November 20 and 21, 2038.
Craige