Format dateTime properties does not work

[christophtaubeneder]

Hi,

we are developing a CAP Fiori Elements V4 app and have embedded the change-tracking plugin.
We are facing an issue with a field of type DateTime which is shown in the UI in the format saved on DB.
Neither the Date and Time are formatted correct, nor the timezone is taken into consideration.
We annotated the dateTime field for change-tracking. In the UI we display the value of the field together with the corresponding timezone.
The change-tracking UI does not display the value as what we would expect:

Annotated DateTime field with annotation to the TimeZone

Changelog annotation for the DateTime field

DateTime field respecting the TimeZone in our UI displayed

DateTime field not formatted and not respecting TimeZone within the change-tracking table

Could you please help with this issue? There is already an existing pull request for formatting a date field which is a similar problem

@cap-js/asyncapi: 1.0.3
@cap-js/cds-test: 0.4.0
@cap-js/cds-typer: 0.36.0
@cap-js/cds-types: 0.13.0
@cap-js/change-tracking: 1.0.8
@cap-js/db-service: 2.2.0
@cap-js/hana: 2.1.1
@cap-js/openapi: 1.2.3
@cap-js/sqlite: 2.0.2
@sap/cds: 9.1.0
@sap/cds-compiler: 6.1.0
@sap/cds-dk: 9.1.0
@sap/cds-dk (global): 9.1.0
@sap/cds-fiori: 2.0.1
@sap/cds-mtxs: 3.1.0
@sap/eslint-plugin-cds: 4.0.2
Node.js: v20.18.1

Best regards,
Christoph

[Sv7enNowitzki]

Hi @christophtaubeneder ,

As far as I know, the plugin currently doesn't support formatting and there are no plans to implement this feature.
Do you have any updates on this? @nkaputnik

Best Regards,
Wenjun

[christophtaubeneder]

Hi @Sv7enNowitzki ,

thanks for the response.

I think DateTime formatting is a must have feature of the plug-in.
Otherwise you will always have an inconsistent UI behaviour in displaying dateTime fields and using the change-tracking plugin as well.

You will always have, dependent of the location and time zone, different formatting of the date and time. Displaying a data base stored value without formatting is not sufficient in this case.

As already mentioned there is a pull request for formatting dates. Maybe the dateTime formatting could be part of it as well.

I hope this is a clear statement for the importance of formatting.

Thank you.

Best Regards,
Christoph

[christophtaubeneder]

Hi @nkaputnik , @Sv7enNowitzki

do you have any news regarding the issue?

Thanks.

Best regards,
Christoph

[Sv7enNowitzki]

Hello @christophtaubeneder ,

Regarding cds.Date, cds.Time, cds.DateTime and cds.Timestamp, I've made some enhancements, and everything is working fine on my end. However, there is a discussion in the PR about an alternative approach, and I'm not sure how to proceed with it.

Aside from that, since I am just a contributor, we need @nkaputnik 's updates and review.

Best Regards,
Wenjun

[christophtaubeneder]

Hi @nkaputnik , @Sv7enNowitzki

do you have any news regarding the PR?

Thanks.

Best regards,
Christoph

[Sv7enNowitzki]

Hi @christophtaubeneder ,

As you can see, I've already submitted some modifications in the PR and we've discussed this approach. However, the topic owner: @nkaputnik does not quite agree with this solution.

Since @nkaputnik is currently on vacation, we need to wait for him to return for further feedback on this issue.

Best Regards,
Wenjun

[christophtaubeneder]

Hi @schiwekM @Sv7enNowitzki @nkaputnik ,
the dateTime fields are still not formatted in the correct timeZone if it is depending on a certain seperate stored timezone.

As initial reported with this issue we have a seperate timezone field in our entitiy which defines the timezone for formatting the dateTime field to be displayed.

Entitiy:

• timeZone
• dateTimeField

Displaying the dateTimeField is dependent by the stored timeZone of the entity.

If it would be a dateTimeField without a dependency to a seperate timeZone it would be correct if it is displayed in the timeZone of the logged in user.

Best regards,
Christoph

[schiwekM]

Hi @christophtaubeneder,

please excuse the oversight. Will have a look at it.

The current plan would be to consider the timezone will saving the change to the DB and format the saved date accordingly. Would that match your expectation?

Thanks & BR,
Marten