RealtimeClock.GetTime() throw OutOfRangeException on first start

Hi All,

Just after a firmware update on the G120 Module, I use a unit test program to check for the RTC functions.
The first row of this program is the following :


Main()
{
DateTime _currentDT = RealTimeClock.GetTime();
....
}

This line of code throw an ‘Out Of Range Exception’ any time I try to play with ! :wall:

I decided to put previously to this, a SetTime() to a given time which I know to be compliant to the Framework scope :


Main()
{
RealTimeClock.SetTime(new DateTime(2001, 01, 01, 12, 0, 0));

DateTime _currentDT = RealTimeClock.GetTime();
....
}

With this new version, ti goes well even for the Set and the Get…

My opinion so, is that in the RealtimeClock.GetTime() implementation of GHI.PRemium Library, there’s no control on the Datetime matching between the low level implementation and the Framework Datetime consistency…

I already discovered the same type of problem between SQL SERVER and the FRAMEWORK, in which the Datetime.Min and Max are not in the same scope, so that when you want to Set Datetime.Min in an SQL Field, it crashes !

Can you confirm that my opinion is right, and if any fix to the GHI SDK could be provided here and when ?

Thanks for your feedback !

I’m using RTC.GetTime/SetTime with latest FW (4.2.11.1) and G120 without any Problems.

This will happen if RTC has not been previously initialized with a correct date. This is outlined in the example given here for GHI’s RTC Extension:

https://www.ghielectronics.com/docs/29/realtime-clock#258

This is a convenience function to allow you to handle the case of when the RTC loses power or is otherwise reset.

It may be easiest to format the output to be a string in which a date time object can be generated from, rather than a strict type like INT or BLOB. I have to do something similar in every language in which I query SQL from.

@ James -

For SQL, there’s an extension provided in the Framework that enable to get a constant value for SQLDatetime.Min and SQLDatetime.Max… It was an example to explain the case…

In fact I understand that using the try catch is mzandatory with GetTime(). So I will do that…

Thanks for the information.