datetime field won't give more precision in wireFormat than in displayFormat

aaron.dunigan.atlee

I have an editor field with this configuration:

{
     name: 'date',
     type: 'datetime',
     label: 'Date',
     def: function () { return new Date(); },
     displayFormat: 'M/D/YY',
     wireFormat: 'YYYY-MM-DD HH:mm:ss'
 }

This particular editor only allows the create action, and this date field is disabled, so the idea is that it should always auto-fill with the current timestamp when a new row is created. I want precision to the nearest second because I use the timestamp for sorting the table. However, there's no need for the user to see that precision; hence the displayFormat of M/D/YY.

However, when submitted, the value sent to the server is always of the form YYYY-MM-DD 00:00:00. If I include hours, minutes, and/or seconds in the displayFormat, then those values are included in the submitted value.

Is this a bug? Or am I doing something wrong? Is there a workaround so I can display a lower level of precision but send the full timestamp to the server?

rf1234

Just tested it myself and had the same result as you.

I would have the database insert or update the field. No coding required at all.

This is how to define the field in the database:
not null, CURRENT_TIMESTAMP ON_UPDATE CURRENT_TIMESTAMP

using Editor you can read the field but you won't update it yourself. Just use ->set( false ) in your server side code.

If you only want to save the timestamp of CREATE and not update it later in case record updates occur just drop ON_UPDATE CURRENT_TIMESTAMP above.

aaron.dunigan.atlee

Thanks for the response, @rf1234. Yes, of course I can set a timestamp on the backend (I'm not using a SQL database so techniques other than what you've described are required). But it's a bit redundant since I'm already capturing a timestamp on the front end. It just seemed like it might be reasonable to expect the datetime field to respect the level of precision specified in wireFormat.

But as I think about this, I realize that maybe I'm circumventing the point of the datetime field: the UI date picker. If the field I've described were enabled, the user would only be able to pick a date, not a time, so it would be odd to store more precision than the user had selected. Maybe it's best in my case to just use a text field with custom date parsing, since I don't actually need the date picker UI.

rf1234

Yep, I guess it is the date picker that causes the issue. With a text field it should work. I've just tested it.

allan

Hi,

Yes, unfortunately, I would expect there to be loss of precision if the displayFormat does not include all components of the wireFormat. It does a full round trip without attempting any merge of the data - so the wireFormat gets written to the input field in the displayFormat. Then when reading it back it converts from displayFormattowireFormat`.

It is a bit of a flaw that, but any workaround could be difficult - it might not just be time, one might miss out years in the display format for example. If you don't need the extra precision then that's absolutely fine. But if you did, you'd need to use get and set formatters (client-side) to merge in the parts you needed.

Allan

aaron.dunigan.atlee

@allan Thanks for that explanation. I kind of expected there to be an internal representation of the displayed date, but it makes sense the way you've set it up. I think the main conclusion is that datetime is not the right field for what I'm trying to do, since I don't actually need the date picker input.