Support all variable types

[TechnoBerry]

Currently not for all variable types present helpers for creation of variable (e.g. Variable.String("Some string")) and reading a value from variable (e.g. variableInstance.AsString()). It would be great to add helpers for following types:

• Date
• File
• Object

[tsanton]

Hi @AMalininHere!

Any chance that you can look into adding date-related variables any time soon?
Thinking Date, Time & Date-Time should be somewhat easier with the DotNet6 implementation of DateOnly & TimeOnly; i.e. clear definitions & target types that can be emulated as string with previous versions?

Many thanks for this package; enjoying it a lot!

-T

[TechnoBerry]

Hello @tsanton !

Variables of the "Date" type in the Camunda are more like DateTime in dotnet world (https://docs.camunda.org/manual/develop/reference/rest/overview/date-format/). It seems that there is no reason to use DateOnly and TimeOnly since there are no analogs for them in the camunda API.

[tsanton]

Hi again @AMalininHere!

I assuming you know a lot more about this than I do, but prior to writing the message above I stumbled upon this:
https://docs.camunda.io/docs/reference/feel/language-guide/feel-data-types/

It's referencing Java types (somewhat naturally?), and it is DMN specific, but it that made me think that these types were natural supported due to the tight knit nature of BMNP & DMN.

Anyhoo -> I could not find a DateTime (or Date) variable inside Variables.cs; any timeline on that implementation?

Speak soon!

-T

[TechnoBerry]

Hi again!

Yesterday I tried to add support for DateTime (Date variable type) and I had some problems. It's interesting that by default in camunda rest api format of dates contains time zone encoded as sign and 4 digits (rfc822 https://www.ibm.com/docs/en/rtw/9.5?topic=reference-date-time-patterns#wp1026619__wp1027076). Unfortunately, standard dotnet library hasn't support to write timezone in the format which can be parsed by camunda.
So DateTime support may take some time.

B.R.
Alexey

[tsanton]

Hi Again Alexey and sorry for being such a pain!

One thing for sure: date & time formats sucks. Json/XML/Any language: pure unadulterated suffering^^

Again; I'm no expert like yourself, but I though the REST API went for "yyyy-MM-dd'T'HH:mm:ss.SSSZ" ref: https://github.com/camunda/camunda-docs-manual/blob/master/content/reference/rest/overview/date-format.md#:~:text=camunda%20%2F%20camunda%2Ddocs%2Dmanual%20Public&text=The%20REST%20API%20uses%20the,%3A33%3A42.165%2B0100%20.

To me that looks like a standard DateTime.UtcNow.ToString("o").
If that's not the case; can we create a variable with a custom json converter?

Hope I'm not ruining your weekend! :)

-T

[TechnoBerry]

Yes, default date format in camunda is yyyy-MM-dd'T'HH:mm:ss.SSSZ where Z is rfc822 timezone (sign and 4 digits). E.g. 2022-01-01T01:01:01.001+0100 is valid but 2022-01-01T01:01:01.001+01 and 2022-01-01T01:01:01.001+01:00 is not.
Unfortunately when date is serialized using DateTime.UtcNow.ToString("o") camunda can't parse it as java.lang.Date (because it looks like 2022-01-01T01:01:01.001+01:00).

Currently, I think that custom json converter is the only way to support dates.

B.R.
Alexey