Use MySQL internal CURRENT_TIMESTAMP for dates
Use SQL internal data instead of PHP generated timestamps:
`created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
:exclamation: Note, the date/time may be different between the PHP and MySQL server, so there may be an offset between all new vs. existing entries.
To adjust /clean command to work with this change this could probably be used:
WHERE UNIX_TIMESTAMP(`updated_at`) + ? < UNIX_TIMESTAMP(NOW())
PS. Oh god I forgot to create this issue...
@jacklul I noticed that the insertUser and insertChat methods can be passed a $date to override the created_at and updated_at fields. I'm just wondering how useful that actually is, as these fields should be purely about "when was this row added (or updated) to the DB".
What do you think?
Also, probably makes sense to add both fields to all DB tables.
It depends how you look at it, I believe some devs like that those fields are the date when the chat was actually created (date from Update) and updated.
I fully support the change that they should contain dates of record update / creation, it makes more sense. We might simply add a field to the chat/user object that will have a date of first chat action inserted.
Message has the date, forward_date and edit_date fields anyway, so those should be safe.
So it's mainly the Chat itself that is a bit off. Update object also has no date associated to it, so there's no way of getting the exact date/time anyway.
I think we just make the change and let the users know.
Use SQL internal data instead of PHP generated timestamps:
`created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,❗ Note, the date/time may be different between the PHP and MySQL server, so there may be an offset between all new vs. existing entries.
Can this problem be solved by setting the timezone of php and mysql server to be the same?