time_t as int64_t

[niondir]

Description of defect

As stated in the documentation "We will be preparing the Arm Mbed libraries for the year 2038 problem" what does this mean? https://os.mbed.com/docs/mbed-os/v6.11/apis/time.html

I'm programming a clock that must run after 2038 and set_time() seems to get a 32bit time_t. Can I somehow change time_t to be 64 bit, which would probably solve the 2038 problem?

Target(s) affected by this defect ?

All 32 bit systems.

Toolchain(s) (name and version) displaying this defect ?

n/a

What version of Mbed-os are you using (tag or sha) ?

n/a

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

n/a

How is this defect reproduced ?

n/a

[mbedmain]

@Niondir thank you for raising this issue.Please take a look at the following comments:

What toolchain(s) are you using? What Mbed OS version are you using? It would help if you could also specify the versions of any tools you are using? How can we reproduce your issue?

NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'. This indicates to us that at least all the fields have been considered. Please update the issue header with the missing information.

[0xc0170]

I'm programming a clock that must run after 2038 and set_time() seems to get a 32bit time_t

What toolchain do you use? How did you verify it?

[0xc0170]

Looking at ARMClang docs, https://developer.arm.com/documentation/100067/0612/Standard-C-Implementation-Definition/Library-functions?lang=en - time_t is 32bit still 🙄 but it is unsigned int so should be fine.

Also Gcc Arm v8 or later should be fine.

[niondir]

I'm working on

    "MCU_STM32WLE5xC" : {
        "inherits" : [
            "MCU_STM32WL"
        ],
        "extra_labels_add": [
            "STM32WLE5xC"
        ],
        "macros_add": [
            "STM32WLE5xx"
        ],
        "mbed_rom_start": "0x8000000",
        "mbed_rom_size": "0x40000",
        "mbed_ram_start": "0x20000000",
        "mbed_ram_size": "0x10000",
        "bootloader_supported": true
    },

I'm getting 64 bit ms timestamps via LoRaWAN. We will do some testing with times after 2038 and need to find solutions to work with it.