since the Core::Time class depends on functionality available in the particular target, we had to limit the corresponding interface to what is typically common in all targets when coding time/date. We selected the UNIX time, which is counted in seconds since 1.1.1970. Therefore the limitation to 1970. Storing such time values in 32-bit integer we can cover the range till year 2038.
In fact, we plan to add new 64-bit integer data type to Chora language and redesign the Core::Time class to be able to calculate with very, very large date range. This is actually waiting on our to-do list.
I hope, you can workaround this limitation by copy the original Core::Time class and adapting your copy to your needs.
But Paul, UNIX time is SIGNED, and it gives you +- 68 years in BOTH sides of the epoch! Why have you limited it?
yes, you are right. What I said with the limitation in year 2038 was incorrect. In fact, we calculate with unsigned integer to be able to keep running Embedded Wizard created devices a little bit longer > year 2100, which was expected by our customers. See the property Time, it is uint32. With this, however, the class Core::Time doesn't support dates before 1970, which in most applications was not problematic. The value range of 32-bit integers is even limited.
As I have mentioned, we plan already to redesign this part. I have just increased the priority of this issue.
Ask Embedded Wizard
Welcome to the question and answer site for Embedded Wizard users and UI developers.
Ask your question and receive answers from the Embedded Wizard support team or from other members of the community!