Field "Sent on" is always empty

Seems like we have a bigger problem here
While code that interacts with the sent_time field is working, It has the type of datetime but the timestamp is written into the database and the view fails because it doesn't know it is a timestamp and not a datetime string.
For the time I hacked views data so it thinks it's timestamp. But before the major release, we should fix the type of the sent_time field
@jitesh_1 please review and merge my MR

Hello @ReINFaTe,
View MR request #6.

Hi @jitesh_1
As I mentioned above, I'd like not to change type right now and not to force a major release right now.
And even without that you cannot simply change the type in the definition, it's not how it works. Please investigate the field system in Drupal

Mismatched entity and/or field definitions
The following changes were detected in the entity type and field definitions.
Stock notification
The Sent on field needs to be updated

It's from the status page when you change the definition without updating

Hello @ReINFaTe,
The best choice is to update the field type for the future, and I can provide the updating code for doing so. only if you agree.

@jitesh_1
Okay, go ahead, main thing is to properly update the field without losing old data. And of course, do not break displaying and existing code.

Hi @jitesh_1
Sorry for the delay, a lot of work lately.

About your update function, the field type is changed to timestamp, but the database schema is not updated.
\Drupal\Core\Field\Plugin\Field\FieldType\TimestampItem::schema has the type int, but in the database, it is still varchar(20)
I suppose it's because you did not delete the old storage and Drupal left it as "already existing" web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorageSchema.php:1609
You need to delete the old storage definition and create a new one, and also migrate all the old data to it.
It should be done in the transaction, so in case of an error, we don't leave broken data in the database.

@jitesh_1

As for your update, while it can work, probably, I personally don't know about everything Drupal is doing when changing storage definitions nor I can test this on a lot of databases/someone's local patches etc.
I would argue once more, it should be done Drupal way, by deleting old storage, creating new one, and migrating data, in a transaction. That way Drupal would 100% do everything it should, the table can't be left in a broken state etc.

Hello @ReINFaTe,
https://git.drupalcode.org/project/profile/-/blob/8.x-1.x/profile.install Here is a link where you may view this module for this example.

Hello @ReINFaTe,
I alter the field type as you required.

@jitesh_1
A database transaction is missing which can lead to losing data.
There is no point to store and reinsert every field, you need the only one that changed.
You need clear data for that field, otherwise Drupal will handle deletion differently and I suppose this can also be an issue.

Once more, please refer to the existing documentation on Drupal.org

Hello @ReINFaTe,
Use $transaction->rollBack() for error handling.

@jitesh_1
I was sure that default exception handling would rollback the transaction. But it actually is not.
Updated MR !6

Hello @ReINFaTe,
Working Fine merge it and create the stable branch as we spent a lot of time on discussing this issue.

Automatically closed - issue fixed for 2 weeks with no activity.