propagateOrbit function fails on Epoch field format

I am feeding the same tleStruct data to the propagateOrbit function twice, but in one case propagageOrbit is successful, and in the other case it fails with the following error message:

    Error using propagateOrbit
    An error was encountered when propagating the orbit of spacecraft at index 1 using sdp4 orbit propagator.
    error in test_TLE (line 17)
    [r1,v1] = propagateOrbit(epoch_date,tleStruct,PropModel="sdp4",OutputCoordinateFrame="fixed-frame");
    Caused by:
    Error using - (line 43)
    Cannot combine or compare a datetime array within a time zone with one without a time zone.

The tleStruct data looks identical in both cases. In the first case, I use tleread() to input the data and feed it directly to propagateOrbit. In the second case, I write the tleStruct to an Excel .csv file, read it back in as a new tleStruct, and feed it to propagateOrbit. That is when I run into issues with the epoch_date and tleStruct.Epoch fields.

Here is a sample test script:

function test_TLE()
    epoch_date = datetime('09-Mar-2025 07:26:58');
    tleStruct = struct;
    input_pathname = pwd;
    [filename, filepath] = uigetfile(fullfile(input_pathname, '*.tle'));
    fullpath = strcat(filepath,filename);
    [~,name,~] = fileparts(filename);
    csv_filepath = strcat(filepath, name, '.csv');
    if isfile(csv_filepath)
        csvtext = readtable(csv_filepath);
        tleStruct = table2struct(csvText);
        % script fails here:
        [r1,v1] = propagateOrbit(epoch_date,tleStruct, PropModel="sdp4",OutputCoordinateFrame="fixed-frame");
        disp(num2str(r1);      
    else
        tleStruct = tleread(fullpath);
        [r1,v1] = propagateOrbit(epoch_date,tleStruct, PropModel="sdp4",OutputCoordinateFrame="fixed-frame");
        disp(num2str(r1);
        % save struct to file so you can read it in faster the next time:
        tleTable = struct2table(tleStruct);
        tlePath = strrep(fullpath,'.tle','.csv');
        writetable(tleTable, tlePath, 'Delimiter', ',', 'fileType', 'text');
    end
end

input file "day_068.tle":

1 00011U 59001A   25067.89046599 +.00002526 +00000-0 [phone]
2 00011  32.8783  45.0235 1450212 290.5993  54.5192 11.89297186480028

Output file "day_068.csv":

Name    SatelliteCatalogNumber    Epoch             Bstar   RightAscensionOfAscendingNode Eccentricity Inclination ArgumentOfPeriapsis MeanAnomaly  MeanMotion
UNKNOWN                     11    3/8/2025 21:22 0.001324                         45.0235    0.1450212     32.8783            290.5993     54.5192 0.049554049

The Epoch field appears as shown above in the Excel table. When you examine it in the edit field, it says "3/8/2025 9:22:16 PM

The first time you run the script, it will read the TLE file and create a tleStruct for propagateOrbit() to read. This call is successful. It then outputs a new "day_068.csv" file to save time on subsequent function calls.

The second time you run the script, it reads the "day_068.csv" file and converts it to a tleStruct. When you attempt to read this

tleStruct into propagateOrbit(), it throws an error.

Apparently propagateOrbit calls arithUtil(a,b) which checks for datetime compatibility and throws an exception.

The time fields appear identical to me in both cases, when I examine them in the tleStruct.Epoch field. Is Excel doing something funny to the datetime structure?

[dpb]

"Is Excel doing something funny to the datetime structure?"

Excel is notoriously bad in handling dates, particularly if it is interpreted as a date/time field. I'm not sure just where it's going wrong there, but I'd be pretty sure it's in that translation into/back out of Excel that is causing the problem.

Why not forego Excel altogether if the point is to save processing time on subsequent case and just save the desired variable(s) in native MATLAB .mat format? It/they will be read back in then identically as were in memory to the identical bit pattern besides being a much smaller file size and faster operation.

Answer 1

[Umar]

Hi @Kurt,

Wanted to close the loop on the Excel/datetime thing properly before saying anything definitive.

Ran a couple of tests on my end first: round-tripped a datetime through writetable/readtable in plain MATLAB, no Excel involved — came out clean, TimeZone empty both sides, values identical. Then did the same thing with a full struct shaped like your actual tleStruct (Name, SatelliteCatalogNumber, Epoch, all the fields) — also completely clean. So that rules out writetable, readtable, struct2table, and table2struct as the cause — none of them introduce the mismatch on their own.

That leaves Excel as the only part of your workflow we haven't directly tested, and by elimination it's the most likely explanation — dpb's instinct about Excel and dates lines up with that. If you get a chance and don't mind, one quick way to confirm it directly: take a fresh CSV, open it in real Excel, save it (even without changing anything), read it back into MATLAB, and check tleStruct.Epoch.TimeZone before and after. If that's what introduces the mismatch, it'll confirm it outright rather than just by process of elimination.

That said — since what you're actually trying to do is just cache the parsed struct so you're not reprocessing that huge file every time, the practical fix doesn't depend on nailing the exact mechanism. save()/load() with a .mat file sidesteps the whole thing, since it stores the datetime exactly as it exists in memory with no text step for anything to go wrong in. Probably the simplest path forward regardless of what Excel turns out to be doing.

[Walter Roberson]

Excel does not store the timezone. It appears that writetable() strips out the timezone information and writes the localtime relative to the timezone (rather than writing a UTC timestamp.)

T1 = datetime(1980, 2, 29, 19, 00, 0)

T1 = datetime
   29-Feb-1980 19:00:00

T1.TimeZone

ans =

  0×0 empty char array

T2 = datetime(1980, 2, 29, 19, 00, 0, 'timezone', 'America/Chicago')

T2 = datetime
   29-Feb-1980 19:00:00

T2.TimeZone

ans = 'America/Chicago'

D = table(T1, T2)

D = 1×2 table
             T1                      T2         
    ____________________    ____________________

    29-Feb-1980 19:00:00    29-Feb-1980 19:00:00

Filename = tempname() + ".xlsx";
writetable(D, Filename)

E = readtable(Filename)

E = 1×2 table
             T1                      T2         
    ____________________    ____________________

    29-Feb-1980 19:00:00    29-Feb-1980 19:00:00

E.T1.TimeZone

ans =

  0×0 empty char array

E.T2.TimeZone

ans =

  0×0 empty char array

OutFolder = tempdir();
filenames = unzip(Filename, OutFolder)

filenames = 1×7 cell array
    {'/tmp/[Content_Ty…'}    {'/tmp/_rels/.rels'}    {'/tmp/xl/_rels/wo…'}    {'/tmp/xl/sharedSt…'}    {'/tmp/xl/styles.x…'}    {'/tmp/xl/workbook…'}    {'/tmp/xl/workshee…'}

dbtype( filenames{7} )

1     <?xml version="1.0" encoding="UTF-8"?><worksheet xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships" xmlns:xdr="http://schemas.openxmlformats.org/drawingml/2006/spreadsheetDrawing" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:x14ac="http://schemas.microsoft.com/office/spreadsheetml/2009/9/ac" mc:Ignorable="x14ac"><dimension ref="A1:B2"/><sheetViews><sheetView workbookViewId="0"/></sheetViews><sheetFormatPr defaultRowHeight="15"/><cols><col min="1" max="1" width="3.140625" customWidth="true"/><col min="2" max="2" width="3.140625" customWidth="true"/></cols><sheetData><row r="1"><c r="A1" s="0" t="s"><v>0</v></c><c r="B1" s="0" t="s"><v>1</v></c></row><row r="2"><c r="A2" s="1"><v>29280.791666666668</v></c><c r="B2" s="1"><v>29280.791666666668</v></c></row></sheetData></worksheet>