We are currently performing an upgrade to our software. This upgrade will bring MediaWiki from version 1.31 to 1.33. While the upgrade is being performed on your wiki it will be in read-only mode. For more information check here.

User talk:TheSatanicSanta

From Fire Emblem Heroes Wiki
Jump to: navigation, search

Request for additional Cargo functions[edit source]

Could you please add MOD, FROM_UNIXTIME, and UNIX_TIMESTAMP to $wgCargoAllowedSQLFunctions? --HertzDevil (talk) 10:43, 4 September 2019 (UTC)

Requesting MOD get enabled. Datetimes are already stored as unix timestamps, is there a table you have which has timestamps not stored as datetimes, and if so, is it possible to transition them over to datetimes? Or is there some other reason that those two functions are needed? TheSatanicSanta (talk) 19:49, 5 September 2019 (UTC)
On MySQL which this wiki uses, DateTime is stored as DATETIME, which is converted into YYYYMMDDHHmmss when used in a numeric context (same for MySQL's TIMESTAMP type). This is different from the number of seconds since epoch, which is what UNIX_TIMESTAMP returns. --HertzDevil (talk) 04:59, 6 September 2019 (UTC)
Why do we need the number of seconds since epoch? TheSatanicSanta (talk) 16:54, 6 September 2019 (UTC)
It is mostly to simplify queries involving time calculations, without having to resort to Lua every time. The original motivation is to check whether a datetime fits into an indefinitely repeating event:
|where=MOD(UNIX_TIMESTAMP()-UNIX_TIMESTAMP(StartTime),CycleTime)<AvailTime
where CycleTime and AvailTime are given in seconds; DATEDIFF cannot be used here, since these two values are not guaranteed to be whole days. FROM_UNIXTIME is requested for symmetry. The other alternative is to use TIMESTAMPDIFF:
|where=MOD(TIMESTAMPDIFF(SECOND,StartTime,NOW()),CycleTime)<AvailTime
but Unix timestamps are more flexible in case other time calculations are needed in the future; besides, conversion to and from Unix timestamps is already available with {{#time:U}} and {{#time:...|@}}, but these are only usable as SQL display fields, not inside the other query parameters. --HertzDevil (talk) 17:51, 6 September 2019 (UTC)
How come you aren't tagging events as you're entering them? If I'm understanding correctly, you're trying to avoid entering metadata about an event and instead determine what series it's a part of by parsing the timestamp. Is this correct? Do you have any other use cases? It's a pretty significant amount of review to add new SQL functions as they need to be enabled platform-wide, is the reason we're making such a big deal about it, SatanicSanta asked me to help figure out if there's another possible approach (you can reply on my talk page so I see a notification if you want). --RheingoldRiver (talk) 18:37, 6 September 2019 (UTC)