Year 2038 problem in the context of Automation Runtime

Share Info & Ideas How-To & Wikis
,
1

Hello B&R Community!

I received a few questions from customers about the Year 2038 problem and the concerns about it, so I wanted to share with you how this is solved in the context of B&R Automation Runtime.

What is the Year 2038 problem?

Some systems store time as the number of seconds since 1 January 1970, 00:00:00 UTC.
If this value is stored as a signed 32-bit integer, the maximum value is 2,147,483,647 seconds, which corresponds to 19 January 2038, 03:14:07 UTC.

After that, the value can overflow and be interpreted incorrectly, which may lead to wrong dates or time calculations.

For more background, see:
https://en.wikipedia.org/wiki/Year_2038_problem

Is this issue solved on B&R systems?

Yes. The operating system underlying Automation Runtime 6.x, based on VxWorks 7.x, has solved the Y2038 problem.
A 64-bit data type is used in the underlying operating system. In Automation Runtime, an unsigned 32-bit data type is used with the limits documented in our AS Online Help:

Limitations to date time setting

Filipe

9 Likes
2

Thanks for sharing, Filipe. Good to know that we are safe :slight_smile:

1 Like
3

Hi,

thanks for the information! Good to be safe with AS6 but what about legacy machines based on AS4? If I understand the Wikipedia article correctly, it will restart from the year 1901. How can we fix it for AS4 then (in 2038 :slight_smile: )?

BR
Eugen

4

Hi @eugen.c ,

The operating system underlying AR 4.x (VxWorks 6.x) has the Y2038 problem.
A fix for AR 4.x is not planned. AS/AR 4 will be legacy soon, we have to focuss on AS/AR 6. :slight_smile:

Best regards

Filipe

1 Like