Framework: Why not use timestamps in jobs table?

[4unkur]

https://github.com/laravel/framework/blob/6.x/src/Illuminate/Queue/Console/stubs/jobs.stub

As you can see, jobs table have fields:

            $table->unsignedInteger('reserved_at')->nullable();
            $table->unsignedInteger('available_at');
            $table->unsignedInteger('created_at');

I'm wondering, why they are not timestamps?

[driesvints]

Hi there,

Thanks for reporting but it looks like this is a question which can be asked on a support channel. Please only use this issue tracker for reporting bugs with the library itself. If you have a question on how to use functionality provided by this repo you can try one of the following channels:

• Laracasts Forums
• Laravel.io Forums
• StackOverflow
• Discord
• Larachat
• IRC

However, this issue will not be locked and everyone is still free to discuss solutions to your problem!

Thanks.

[Synchro]

FWIW, I just ran into exactly this and wondered the same thing - I expected this to be considered a bug if there isn't some obvious reason we have missed for it not to be, which I assume is why the original report was phrased somewhat passively. Laravel uses proper timestamps for such fields elsewhere, so it's not clear why it would not do it here as well.

This is actually a duplicate of #23571, however, the reason given there is not correct - while the fields may be presented as UNIX timestamps, that has little bearing on their _storage format_ - MySQL (and other databases) is more than capable of accepting and generating timestamp values in UNIX timestamp format without using a non-semantic integer field type to store them in, just as it would be inappropriate to store ISO-format timestamps as strings.

In other words, if there is no particular reason for these not to be timestamps, then this is indeed a bug and it is correct that it was reported here.

[KeyShang]

Why other tables use timestamp, only the jobs table use unsignedInteger?
Isn’t consistency what we care about when writing codes?