apache / apache/nuttx

[FEATURE] "portable" implementation for POSIX's uint64_t time.

Open
#18,849 0 comments 0 reactions 0 assignees View on GitHub
Arch: avr Arch: avr32 Arch: avr8 Arch: mips Arch: risc-v Arch: simulator Arch: x86 Arch: xtensa Arch: z16 Arch: z80 Area: Documentation Area: Kernel Area: Modularity Area: Posix Area: Standards Board: all Type: Enhancement Type: Improvement
Dominant language
C
Stars
4k
Forks
1.7k
Avg merge
1d 17h
Merged PRs (30d)
237

Description

### Is your feature request related to a problem? Please describe.

* We are moving to POSIX compliant time representation (The Open Group Base Specifications Issue 8 IEEE Std 1003.1-2024 [1][2][3]) with `uint64_t`.
* POSIX `sys/types.h` [3] defines:
> `time_t` as "Used for time in seconds"
> `time_t` shall be an integer type with a width (see ) of at least 64 bits.
* What it solves:
* year 2038 problem.
* 32-bit system clock wrapped in ~497 days and almost every active board already enabled it.
* runtime time overflow calculation errors after some weeks.
* What it breaks:
* 8/16/32-bit platforms are most likely impacted by increased code size (i.e. ~2KB) when `long long` type is not natively supported.
* time calculation will be slower on older platforms.
* non-atomic time access (needs some additional protection).

This is a long standing challenge discussed on our mailing list [4][5].

Related PR: https://github.com/apache/nuttx/pull/18840, https://github.com/apache/nuttx/pull/14460, https://github.com/apache/nuttx-apps/pull/3468.

[1] https://pubs.opengroup.org/onlinepubs/9799919799/
[2] https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/time.h.html
[3] https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/sys_types.h.html
[4] https://www.mail-archive.com/dev@nuttx.apache.org/msg12060.html
[5] https://www.mail-archive.com/dev@nuttx.apache.org/msg14534.html

### Describe the solution you'd like

1. We are moving towards POSIX standard compliant time representation with `int64_t` type as **default**.
2. We need alternative **portable** implementation of the time representation on platforms that do not support native `int64_t` type that will solve size increase, slow down, and non-atomic time access protections, but still assure POSIX compliant interface.
3. Form the OS perspective both implementations should provide exactly the same and one-to-one compatible / replaceable solution, but the "portable" should assure best fit for the small architectures.

### Describe alternatives you've considered

_No response_

### Verification

- [x] I have verified before submitting the report.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.