We have made the fix. Please try a recent build of QuickOPC 5.35 from www.opclabs.com/products/quickopc/downloads (it should identify itself as 5.35.1173.1 or higher).

Note that we have not actually tested the behavior in question - lacking a server that would send us such data. But the fix was not complex and should hopefully work. You should now get DateTime.MaxValue for "offending" values.

Best regards

Thank you - then you should have no problem with the fix, as it would be just a new build of the same version. You will just reinstall QuickOPC and rebuild with the new assemblies.

There are several issues in here. None of them is your fault.

The underlying problem is that .NET-s DateTime range cannot fully represent all valid FILETIME values; and the FILETIME structure is what OPC "Classic" uses to represent various timestamps. The FILETIME is essentially a 64-bit (unsigned) integer.

But, the DateTime is wide enough to cover all "reasonable" dates. The OPC server has apparently chosen to use some extreme FILETIME values to represent some special states. There is nothing in Windows or OPC specs that forbids doing this, although I would argue that it can be inferred from the OPC specs that it is not a good idea. Zero FILETIME is not a problem - it convert to a valid DateTime (January 1, 1601) already. The problem is therefore in big values (or, when FILETIME is treated as a signed integer, in values like -1), because they go over the DateTime.MaxValue (which is 23:59:59.9999999 UTC, December 31, 9999).

And, on our side, we have not covered this case correctly. It should not throw in the way it does. It should do something better. You currently have no way of trapping it; neither you actually should be required to do it.

The question is what to do in such case. It would be ideal to have some way to indicate that the problem has occurred, but I am not sure how, but it would require a change in the API which we cannot do at the moment. I am making a note for future consideration. For now, we will make a fix that will convert all FILETIME-s that are too high to DateTime.MaxValue (which you can then detect if so required). And, no exception will be thrown.

I will post here when the fix is available - should be hopefully by end of the week.

BTW, just for record, the exception message (which comes from Microsoft conversion function) is not really appropriate either - it says "Not a valid Win32 FileTime", but there really aren't any invalid values (msdn.microsoft.com/en-us/library/system.runtime.interopservi...mtypes.filetime(v=vs.110).aspx ) - just values that cannot be converted to DateTime.


Regarding the QuickOPC version: Thank you - but I actually needed one more digit to the right. The reason I have asked is that we can only provide a fix to the current version, which is 5.35 (and of course it will be present in all subsequent versions). You can determine the full version e.g. by looking at the first page of the install Wizard (or from the filename of the setup package), or from the properties of any assembly, or from the accompanying documentation files, or by clicking "About" in one of the Demo applications.

Best regards

Which QuickOPC version are you using please? I will answer then.