FDateTime Customization as a Text Block Entry could use an update.

Development Pipeline & Plugins
, ,
1

We’ve gotten feedback from designers that the format for FDateTime entry is not designer friendly. It’s currently a text block and the format is not immediately obvious. The scope of use on our project isn’t incredibly widespread, so it didn’t feel completely necessary to write a custom solution, especially as how we try to avoid creating merge issues with new Epic drops.

Relevant code:

DateTimeStructCustomization.h/.cpp

SPropertyEditorDateTime.h/.cpp

Is there anything already on the radar for this? I think even a tooltip that describes the format could go a long way, but a new widget for the property could be a more permanent solution.

2

Steps to Reproduce
No repro, new feature request.

3

Hi there,

There is complexity with the Date Time Editing; it’s also always presented in the local time zone of the editor, but stored as UTC.

Localising the date and time to the locale would also be an option; it is possible to use FText::AsDate to convert it to the localised version, eg Day/Month/Year vs Month/Day/Year in that styling, which may be more intuitive to editors.

Converting back, however, I don’t think it is as exposed to other modules in C++.

That being said, you do not need to modify the engine to replace the property’s customization.

Creating an editor-only module or plugin that is loaded late in the engine’s initialisation, ie PostEngineInit after the normal date time customisation has been applied will allow you to override the default property customisation. The key function to achieve this FPropertyEditorModule::RegisterCustomPropertyTypeLayout

I put one together that you are welcome to use, modify, or re-create that might suit your needs

[Image Removed]It keeps the normal way of editing FDateTime, but adds child elements for setting them as a date or time individually.

Again, it converts to the local time zone for display, but is stored as UTC, My preference would be to display as UTC if it were critical to the operation to reduce input errors.

You could remove the displayed timezone conversion from property customisation if you wanted to as well.

You can then parse it as the designers wish to edit it.

You may also want to do something like FVectors, which are broken further into components on a single row, with a preceding XYZ label.

I have attached a small project with an editor module inside, which demonstrates how you could do this.

I will reassign this to an epic staff member to comment on the future of FDateTime property customisation.

Kind Regards

Keegan GIbson

4

Hey there, in addition to Keegan’s suggested engine modification I’ve gone ahead and entered an internal feature request for a date time picker. Since this is a bigger task, I’m not sure when we’ll get to implementing this.

In the meantime, I have implemented your suggestion of adding a tooltip to the FDateTimeStructCustomization text box with CL 44446913:

[Image Removed]

5

Thank you both, these were very helpful responses.

[mention removed]​ - you mentioned an attachment, but I am unable to locate it. Regardless, you gave me enough info to take a crack at it myself.

Thank you both again. Feel free to close this issue at your convenience.

6

Hi, I might have uploaded it to the question as a whole, and I’m now not sure if you can see that.

I’ll attach it directly to this reply.

Take a look at the SplitDateTimeCustomisation.h/cpp for inspiration and the Blank_Edtor module startup function, which registers the new customisation.

Also note in the .uproject file, the Blank_Editor loading phase has been changed so that it loads after the detail customisations DateTime and so overrides it as the base.

If there are any further feature requests, suggestions, or questions, please don’t hesitate to create a new support request.

Kind Regards

Keegan Gibson