This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(73.60000000000001, 16%, 17%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EYS%3C/text%3E%3C/svg%3E)
Currently, we are evaluating the communication with IoT HUB of Azure with AzureRTOS
by referring to the following sample project.
Azure_RTOS_6.1_Renesas_RX65N_RSK_2MB_e2studio_CCRX_Sample_2021_11_19.zip
sample_azure_iot_embedded_sdk
In the above implementation, the system time is synchronized by SNTP, and it seems that
it operates based on the time in seconds acquired there, but the time information seems
to be 32 bits.
Won't this cause the Year 2038 problem?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(54.400000000000006, 38%, 15%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EQ%3C/text%3E%3C/svg%3E)
Hello @yoji sato This is a great question, thanks for posting this!
Community SME's on this topic or our team will review your scenario and circle back at the possible earliest time.
Just FYI for the readers: What is Y2038?
The problem exists in systems which measure Unix time — the number of seconds elapsed since the Unix epoch (00:00:00 UTC on 1 January 1970) — and store it in a signed 32-bit integer. Ref
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(249.60000000000002, 28.999999999999996%, 34%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ELD%3C/text%3E%3C/svg%3E)
Hi @yoji sato san, we confirmed that this was a bug in the code that requires a fix. We have planned to fix that in our next release. Many thanks for reporting that. Also please let us know if this problem impacts on your project so that we can provide some patch code for you as an interim solution.
Hi, LiyaDu-9723 san,
Thank you for making sure.
I understand that they are bugs and need to be fixed.
We are developing a system for a customer, and we need to incorporate this feature and release it in March.
Therefore, we would like you to provide a patch or a correction method by the middle of February if possible.
Hi yojisato-san, yes we can provide you the patch code around mid of Feb for your project. If we can have your email address we can send you the files then.
Hi, LiyaDu-9723 san,
We would like you to provide a patch code.
So is it possible to give you our email address without publishing it here?
If possible, please let me know how to do it.
Hi yojisato-san, we are working on a short term solution and will get back to you soon.
Hi @yoji sato As NTPv3 timestamps are represented as a 64-bit unsigned number in seconds relative to 00:00:00 UTC on 1 January 1900. The integer part is in the first 32bits (136 years), so the time for NTP will overflow in 2036 (1900 + 136). The time in middleware will overflow in 2106 (1970 + 136) since it uses Unix time.
Two options for product.
Some information for reference as below:
Unix time: it is the number of seconds that have elapsed since the Unix epoch, excluding leap seconds, the Unix epoch is 00:00:00 UTC on 1 January 1970.
NTP time: it is the number of seconds elapsed since the Unix epoch (00:00:00 UTC on 1 January 1900).
NTPv3 Timestamp Format : 32-bit for seconds, 32-bit for fraction,
NTPv4 Data Types: There is a 128-bit date format, the 128-bit date format includes a 64-bit signed seconds field spanning 584 billion years and a 64-bit fraction field.
Hi BoChen-0401 san,
Thank you for your reply.
I'm sorry for the late reaction here.
If we can deal with the time obtained by SNTP, is it okay to recognize that the other parts are okay?
In the sample code of sample_azure_iot_embedded_sdk, it seems that the process to generate
ULONG unix_time is performed based on the time information obtained by SNTP.
Is it okay to recognize that if you can handle the time obtained by SNTP well, it will not cause any problems?
sample_azure_iot_embedded_sdk\main.c
/* System clock time for UTC. */
static ULONG unix_time_base;
/* Convert to Unix epoch and minus the current system time. */
unix_time_base = (sntp_seconds - (system_time_in_second + SAMPLE_UNIX_TO_NTP_EPOCH_SECOND));
static UINT unix_time_get(ULONG *unix_time)
{
/* Return number of seconds since Unix Epoch (1/1/1970 00:00:00). */
*unix_time = unix_time_base + (tx_time_get() / TX_TIMER_TICKS_PER_SECOND);
return(NX_SUCCESS);
}
and
netxduo\addons\azure_iot\nx_azure_iot.c
UINT nx_azure_iot_create(NX_AZURE_IOT *nx_azure_iot_ptr, const UCHAR *name_ptr,
NX_IP *ip_ptr, NX_PACKET_POOL *pool_ptr, NX_DNS *dns_ptr,
VOID *stack_memory_ptr, UINT stack_memory_size,
UINT priority, UINT (*unix_time_callback)(ULONG *unix_time))
{
:
:
Hi @yoji sato Yes, the current time issue is only for SNTP, other parts are ok.
Hi BoChen-0401 san,
Thank you for your reply.
If so, is it okay to recognize that the problem can be avoided by taking the following measures?
"If the MSB of the second obtained by SNTPv3 is 0, it is judged to be the time after 2036 (1900 + 136) and converted to UNIX time."
Since some time in 1968 the most significant bit of second has been set, in theory, you are able to calculate the time after 2036 according to the MSB of second if NTP server support it.
Hi BoChen-0401 san,
Thank you for your reply.
So we'll try that way.
Thank you vey much for your support.