Re: [PATCH] Modified localtime fields to default current_timestamp.

[jrmu <jrmu@xxxxxxxxxx>]

I do agree that it may be best to stick with time in unix epoch format.
And thanks for reminding me, there may be some code that relies upon the
timestamp being in that format.

So far, I have not applied that patch.

-- 
jrmu
IRCNow (https://ircnow.org)

On Wed, Apr 19, 2023 at 07:54:26PM +0200, ircnow support wrote:
> is there any particular reason for changing this?
> 
> botnow currently stores time in unix epoch format (ie "1678041898" as a string,
> no clue why...). this changes the default value to an iso8601-like
> format (ie "2023-04-19 17:36:27"). I do love some iso8601, but changing the
> timestamp format seems like needless bikeshedding. it would make the database
> slower, existing databases would have to be converted, and botnow's behavior
> would have to be modified too.
> 
> if this is for human-readability, sqlite's date convenience functions may
> be used when SELECTing to show it as any format on the fly. see also
> https://www.sqlite.org/lang_datefunc.html
> 
> additionally it does not give the column a defined type, just a default
> value (you probably want INTEGER, for unix timestamps). not that it
> particularly matters because of how flexable sqlite is, but it is inconsistent
> with other columns.
> 
> fun fact, in sqlite VARCHAR(length) is meaningless, the length is discarded
> and it just turns into sqlite's STRING for compatibility with other sql
> engines.
> 
>

Attachment: signature.asc
Description: PGP signature