ISO8601 compatibility for DateTime ToString

[networkfusion]

Description

Adds DateTime.ToString("o"); so that ISO8601 compatible datetimes can be generated.

Workarounds from the full framework are:

• uses the char Z instead of the datetime Culture specifier K as (I dont think) we support it.
• only supports millisecond precision (as we dont support further decimal places, and would be a waste to add extra zeros).

Motivation and Context

Option was missing.

• Resolves DateTime.ToString does not support "o" for ISO8601 Home#853.

How Has This Been Tested?

Screenshots

Types of changes

• Improvement (non-breaking change that improves a feature, code or algorithm)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Config and build (change in the configuration and build system, has no impact on code or features)
• Dependencies (update dependencies and changes associated, has no impact on code or features)
• Unit Tests (work on Unit Tests, has no impact on code or features)
• Documentation (changes or updates in the documentation, has no impact on code or features)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[nfbot]

Hi @networkfusion,

I'm nanoFramework bot.
Thank you for your contribution!

A human will be reviewing it shortly. 😉

[josesimoes]

It would be great if you could update the DateTime unit tests to cover this change.

[networkfusion]

It would be great if you could update the DateTime unit tests to cover this change.

It is already there, but broken...

CoreLibrary/Tests/NFUnitTestSystemLib/UnitTestDateTime.cs

Line 161 in 126b65d

//public void DateTime_ToStringTest7()

[josesimoes]

Can you give it a try and fix whatever is not working there? Only for the string formats that we support, of course. 😁

[networkfusion]

Assuming the test I have uncommented and updated is reasonable... All tests now pass!
Of note, it seems we cannot handle sub second precision of over 3dp, and we should really just return 0 for extra digits (for fff + ffff rather than an argument exception in another PR?!). Although... Unless it is meaningful, I dont think we should bother returning extra "0"'s in the .ToString("o"), as that just adds data to things like MQTT messages, which are generally charged for based on size, and almost all decoders should handle that (unless it is done to ensure float precision)!

[networkfusion]

For reference, this is how it is now decoded:

[josesimoes]

The standard doesn't specify any size for the fractional part. It mentions that it should be agreed between parties.
For reference: https://en.wikipedia.org/wiki/ISO_8601

Seems that the 3 places comes from from MS SQL formats (and the fact .NETMF was a lightweight platform).
We can surely change that and go with the full fffffff places following the .NET format (and pretty much everyone else).

[josesimoes]

Regarding the Unit Test: well... that's the bare minimum there... the call could return "carrots" and the test would still be green . 🤣

It should be improved to do a proper comparison and validate the expected outcome.
Do you want me to look into that, or you'll it?

[networkfusion]

Regarding the Unit Test: well... that's the bare minimum there... the call could return "carrots" and the test would still be green . 🤣

It should be improved to do a proper comparison and validate the expected outcome. Do you want me to look into that, or you'll it?

If you could, that would be awesome.

RE the fffffff, I was more going on MS documentation for o than the ISO standard itself:

[josesimoes]

Should be OK now, fully compliant with .NET and properly tested.