Re: Change time_t to signed type

[Gregory Nutt]

Here are solutions and details of implementations as implemented by 
other OSs and file systems (the year 2038 problem does apply to 
timestamps and meta-data in file systems too!  Including NFS). See 
https://en.wikipedia.org/wiki/Year_2038_problem



 Implemented solutions

 * Starting with Ruby
    version
   1.9.2 (released on 18 August 2010), the bug with year 2038 is
   fixed,^[16]
    by
   storing time in a signed 64-bit integer on systems with 32-bit
   |time_t|.^[17]
   
 * Starting with NetBSD  version
   6.0 (released in October 2012), the NetBSD operating system uses a
   64-bit |time_t| for both 32-bit and 64-bit architectures.
   Applications that were compiled for an older NetBSD release with
   32-bit |time_t| are supported via a binary compatibility layer, but
   such older applications will still suffer from the Y2038
   problem.^[18]
   
 * OpenBSD  since version 5.5,
   released in May 2014, also uses a 64-bit |time_t| for both 32-bit
   and 64-bit architectures. In contrast to NetBSD
   , there is no binary
   compatibility layer. Therefore, applications expecting a 32-bit
   |time_t| and applications using anything different from |time_t| to
   store time values may break.^[19]
   
 * Linux  originally used a 64-bit
   |time_t| for 64-bit architectures only; the pure 32-bit ABI
    was not
   changed due to backward compatibility.^[20]
   
   Starting with version 5.6
   
   of 2020, 64-bit |time_t| is supported on 32-bit architectures, too.
   This was done primarily for the sake of embedded Linux
   
   systems.^[21]
   
 * GNU C Library  since
   version 2.34 (released August 2021), added support for using 64-bit
   |time_t| on 32-bit platforms with appropriate Linux versions. This
   support can be activated by defining preprocessor macro |_TIME_BITS|
   to |64| when compiling source code.^[22]
   
 * FreeBSD  uses 64-bit |time_t|
   for all 32-bit and 64-bit architectures except 32-bit i386, which
   uses signed 32-bit |time_t| instead.^[23]
   
 * The x32 ABI  for Linux (which
   defines an environment for programs with 32-bit addresses but
   running the processor in 64-bit mode) uses a 64-bit |time_t|. Since
   it was a new environment, there was no need for special
   compatibility precautions.^[20]
   

 * Network File System
    version 4 has
   defined its time fields as |struct nfstime4 {int64_t seconds;
   uint32_t nseconds;}| since December 2000.^[24]
   
   Version 3 supports unsigned 32-bit values as |struct nfstime3
   {uint32 seconds; uint32 nseconds;};|.^[25]
   
   Values greater than zero for the seconds field denote dates after
   the 0-hour, January 1, 1970. Values less than zero for the seconds
   field denote dates before the 0-hour, January 1, 1970. In both
   cases, the nseconds (nanoseconds) field is to be added to the
   seconds field for the final time representation.
 * The ext4  filesystem, when used
   with inode sizes larger than 128 bytes, has an extra 32-bit field
   per timestamp, of which 30 bits are used for the nanoseconds part of
   the timestamp, and the other 2 bits are used to extend the timestamp
   range to the year 2446.^[26]
   
 * The XFS  filesystem, starting
   with Linux 5.10, has an optional "big timestamps" feature which
   extends the timestamp range to the year 2486.^[27]
   
 * While the native APIs of OpenVMS
    can support timestamps up to
   31 July 31086,^[28]
   

Re: Change time_t to signed type

[Nathan Hartman]

Thank you, Greg, for doing this research and putting this all together here!

This stood out (replying below):

On Wed, Nov 6, 2024 at 8:11 AM Gregory Nutt  wrote:
>   * Linux  originally used a 64-bit
> |time_t| for 64-bit architectures only; the pure 32-bit ABI
>  was not
> changed due to backward compatibility.^[20]
> 
> 
> Starting with version 5.6
> 
> 
> of 2020, 64-bit |time_t| is supported on 32-bit architectures, too.
> This was done primarily for the sake of embedded Linux
> 
> systems.^[21]

So, Linux (since 5.6) uses 64-bit time_t on 32-bit archs -- emphasis
on "primarily for the sake of embedded Linux systems" -- It sounds
like that was done because embedded systems are expected to function
in machinery, infrastructure, etc., things that are long-lived. This
is exactly my experience with embedded systems. So we need to be
mindful of Year 2038 problems.

I'd like to also reply to raiden00pl:

On Wed, Nov 6, 2024 at 6:20 AM raiden00pl  wrote:
>
> Unconditional int64_t time_t is a waste of resources for small systems.
> Easier porting of *some* applications for *some* users at the expense of
> other users is not the solution.
> Nuttx has a lot of options anyway and that is nothing more than a
> consequence of `INVIOLABLES.md`.
> For some people this is a disadvantage, for others it's a great opportunity
> to fine tune their system.
> Kconfig with choices, as Tomek says, seems like a good option to me. Next
> we can make the default
> value dependent on DEFAULT_SMALL. But whether the default 32 bit time
> should be signed or unsigned,
> I have no opinion.

This is very similar to my thoughts. It is good that we have Kconfig
and developers can fine-tune their systems to their needs and
constraints. In general, I think our defaults should make it as easy
as possible to get up-and-running, but we should give developers
options (through Kconfig) because they know best what they are trying
to achieve with NuttX.

I am +1 for a Kconfig.

I am okay with any of these possibilities:
* make the default depend on DEFAULT_SMALL like raiden00pl suggests
* or make the default 64-bit on all 32-bit and 64-bit systems and
32-bit on all 8-bit and 16-bit systems
* or just make the default 64-bit on ALL systems, and if you are
trimming resources, you can make a judgment call whether to reduce it
to 32-bit

Example where it makes sense to reduce time_t, even though Year 2038
problem: a toaster with a 8-bit MCU. As long as you implement time
comparisons to work correctly through rollover, your bread will come
out toasted correctly! Same for coffee maker, dishwasher, etc.

Cheers,
Nathan

Carleton University InSpace Preliminary Design Review

[Matteo Golin]

Hello everyone,

As you might know, Carleton University InSpace 
is a rocketry design team based out of Ottawa, Canada and we are adopting
the use of NuttX for both our telemetry system and our hybrid rocket motor
control system this year. We would like to invite you to our preliminary
design review (PDR), which is an opportunity for our team to showcase our
initial designs and seek feedback from industry professionals, alumni and
academics. We know that the NuttX community is international, so you will
be able to join us virtually using Microsoft Teams. This event will be 3
hours long on *November 15th* from *6:00PM - 9:00PM EST. *There will be
several student presenters, including myself, who will present the avionics
systems designs for the 2024-2025 academic year. We aim to leave lots of
time for questions and feedback about our designs. Feedback given during
these PDRs are critical for making our designs flight-ready for competition
in the summer. We have a very limited timeline because of our academic
responsibilities, and manufacturing of our electronics will take place
before the end of December, hence the need for lots of feedback.

Our aim with this invitation is to have several attendees from the NuttX
community who can provide feedback on both our software and hardware
designs. We want to make sure that we are leveraging all of NuttX's
features and not overlooking any support or lack of support for certain
devices and features.

*Project descriptions:*

Our first project is a flight computer telemetry system. It will use an
STM32H743 MCU on a single board with several peripheral sensors including a
GPS, IMU, barometric pressure sensor, temperature sensor and
current/voltage sensors for battery monitoring. The system will transmit
flight state data over LoRa radio at 433MHz by interfacing with a student
designed radio board. It will also log this flight data to a power-fail
safe filesystem on an SD card in flight, then copy all logs to a FAT
partition for easy extraction upon landing. The system is designed to have
72 hours of battery life and provide reliable downlink data transmission to
our ground station systems.

Our second project is a control system for our student designed hybrid
rocket motor. A hybrid rocket motor is a motor which makes use of both
solid fuel (paraffin wax) and a gaseous oxidizer (nitrous) as a propellant.
Our team has historically only flown solid propellant motors which are
commercially obtained, so it will be a huge first for the team. Nitrous is
quite unstable when left for long periods of time inside an oxidizer tank,
so we require stringent control mechanisms to be able to safely operate our
plumbing system from several thousand feet away from the rocket. This is
done via network control over a network bridge composed of Ubiquity
liteBeam hardware. The control system on the rocket side and remote control
side will be running NuttX.

*How you can attend:*

If you would like to attend our PDR virtually, please RSVP
avion...@cuinspace.ca so we can track attendance. We will send everyone who
RSVPed an email with the Microsoft Teams joining details a few days prior
to the PDR. You can find the detailed schedule below.

If you plan on attending the PDR, please take some time a few days in
advance of the 15th to review our detailed design document
.
This document's purpose is to serve as written documentation of our
systems' designs in as much detail as possible. You can refer to this
during our PDR, and also use it to come up with any questions you may want
to pose in advance. If you can't attend the PDR, you are still most welcome
to read our design document and provide us with written feedback. I don't
want to clutter the NuttX forums with our design review outside of this
initial invitation, so please provide your feedback to avion...@cuinspace.ca.
Note that the document is still a work in progress because of our limited
student schedules, and will receive a large number of updates in the next
few days leading up to our PDR. I would recommend checking on it around the
11th or 12th. Any information added to the document beyond that date will
be equally presented at our PDR, so you will not miss anything.


*Avionics PDR Schedule (November 15th, 6:00 - 9:00PM EST)*

   - 6:00PM - Admin Intro
   - 6:10PM - Avionics Deployment Electronics
   - 6:20PM - Telemetry System
   - 7:50PM - Hybrid Rocket Motor Control System

Thank you for your consideration and InSpace hopes to see some of you
there! We're very excited to be using NuttX!
-- 
Matteo Golin
Avionics Lead
Carleton University InSpace