Is your feature request related to a problem? Please describe.
The OS_stat call currently returns the file time as an int32 member within the os_fstat_t structure, as defined here:

This isn't really documented in the API but the field is a traditional UNIX-style timestamp, which is seconds elapsed since Jan 1 1970 UTC.

This type of timestamp suffers from the "year 2038" bug, where the int32 value rolls over and becomes negative. Although this is 18 years from now, at the timescales of space software development cycles, it is entirely possible that coding being developed now will still be in service at the time this happens, so it should be fixed sooner rather than later.

Describe the solution you'd like
There are two fixes needed:

1. use the OS_time_t representation as used in OS_GetLocalTime and OS_SetLocalTime. This is just for consistency - shouldn't use a different representation of time as the other API calls do.
2. Fix the OS_time_t to accommodate larger timestamp values and/or use a different epoch (latter would be risk but keep the structure the same size).

Additional context
Discussion regarding use of this field in nasa/cFE#519

Requester Info
Joseph Hickey, Vantage Systems, Inc.