Datetime tick precision

[anderson-joyle]

Introduced by #728 and #782.
It happens that there are a few ways to "declare" a DateTimeValue in PFx and not all of them will contain tick information. Examples:

• Expression DateTime(2022,11,22,10,1,22,123) - does not store tick info
• Expression DateTimeValue("2022-11-22T09:59:59.1837513-06:00") - stores tick info
• FormulaValue.new(datetimeVariable) - stores tick info

PFx currently serializes DateTimeValue into the following format (losing tick info):
DateTime(2022,11,22,10,1,22,123)

Question is: do we need to maintain tick info?

[MikeStall]

The issue here is: Do DateTimeValues in the Power Fx language carry tick precision?
The JS implementation does not, and the DateTime() function does not currently accept it.

But C# DateTime does.

This becomes an issue when serializing/deserializing a DateTime - if we do allow ticks, we don't want to lose them when round-tripping through a serializer.

[CarlosFigueiraMSFT]

I would posit that business applications would rarely (never?) need sub-millisecond precision. Is there any reason (besides "C# supports it") that we would need this kind of precision? If not, then the consistency across all platforms would probably make being a millisecond-precision language a better choice.

[cchannon]

Speaking as a client-facing implementer, I mostly agree with @CarlosFigueiraMSFT -- rarely IS the word here -- The exceptions being that sometimes there is a need to sort records by datetimes and avoid any ambiguity.

For example, a valid use case might be to assign record numbering in arrears, or perhaps we're talking about a data integration scenario that absolutely requires a guarantee of FIFO (i.e. numerous additions and subtractions from some record definition could hit within milliseconds and every one of those must be processed in some asynchronous handler, such as a Service Bus).

With those exceptions called out though, I do want to reiterate that the need is quite rare, and the exception illustrations I've offered are admittedly less-than-ideal candidates for "low-code" tooling.

[filcole]

I remember Jonas Rapp asking, and finally getting the datetime precision increased so that the plugin trace log extension in XrmToolbox could be displayed in the correct order.

See rappen/PluginTraceViewer#81

[cchannon]

I'll toss one more thing in here to consider: DateAdd and DateDiff presently do not allow for ticks - they work in milliseconds at their most granular. To adopt sub-millisecond precision must also mean updating these functions (and the existing usages of them out there in the world today) to accommodate the same.