Contents

Template talk:TwitterSnowflake

Creating talk-page to centralize future discussions with redirects, feel free to remove this if anything of substance gets posted. Elliot321 (talk | contribs) 02:52, 22 January 2021 (UTC)[reply]

Using any of the formatting codes with "-" i.e. %-Y, %-H, %-M, %-S, %-j, and %-I while specifying the date format does not work. Is this intended or is this a bug? — Jeluang Terluang (talk) 09:12, 3 February 2021 (UTC)[reply]

@Jeluang Terluang: I'm assuming you're using Module:TwitterSnowflake directly? This uses Lua's date formatting. I'm unaware that things like %-Y work with that. Elliot321 (talk | contribs) 12:46, 3 February 2021 (UTC)[reply]

Thanks for the answer. — Jeluang Terluang (talk) 19:40, 3 February 2021 (UTC)[reply]

Dignidad Ahora is a new article with two errors from {{Cite tweet}}, namely "Lua error in Module:TwitterSnowflake at line 45: attempt to index local 'x' (a nil value)." I'll fix them soon as they are due to the date not being valid as an English date (for example, date=6 de enero de 2021). Previewing the following shows the error.

{{Cite tweet
|user=ExampleUser
|title=ExampleTitle
|number=1346864942662774789
|date=mistake
}}

The problem is from lines 39–40 of Module:TwitterSnowflake:

local date = Date(frame.args.date) or 0 -- if we error here, then an input of no date causes an error, which is contrary to the entire way {{TwitterSnowflake/datecheck}} works
return date - twitterdate

The first line sets date to 0 and the second line tries to subtract twitterdate (which is a valid date from Module:Date) from zero. Module:Date cannot do that so it returns nil and that gives the error above. A better error message would be something like:

return (date - twitterdate) or error("parameter 'date' is invalid", 0)

What should happen? Johnuniq (talk) 02:26, 28 August 2021 (UTC)[reply]

@Johnuniq: ah yes, this should be caught. I would've thought I implemented that instead of an ugly Lua error... but I guess not? Elli (talk | contribs) 02:46, 28 August 2021 (UTC)[reply]

Ah, I see, GKFX converted {{cite tweet}} to Lua at Module:Cite tweet. Not sure if the original coding of the template had this problem - too tired for this tonight, but if necessary I'll fix it in a day or two. Elli (talk | contribs) 02:53, 28 August 2021 (UTC)[reply]

Thanks. I would have fixed it but the "or 0 -- if we error here..." made me think that something special was wanted. The question to be resolved is what should happen if the given date is invalid. Johnuniq (talk) 03:40, 28 August 2021 (UTC)[reply]

Good question. It should probably be an error - I'd have it categorize in . However, as the date parameter isn't necessary, an omitted date parameter should not throw an error, and the error shouldn't be a fatal one (still calculate the date from the snowflake and display that, but also display error text). Elli (talk | contribs) 03:51, 28 August 2021 (UTC)[reply]

Please check error on Marty Kemp — Martin (MSGJ · talk) 21:36, 17 February 2023 (UTC)[reply]

An invalid date ("May 4, 1966 2020") was in |date= so it was GIGO, but perhaps the error should be caught. Nardog (talk) 00:31, 18 February 2023 (UTC)[reply]

I'll note that this template is not longer used in the code of {{cite tweet}}. If you want to catch the error you'll want to look at Module:cite tweet. Elli (talk | contribs) 00:33, 18 February 2023 (UTC)[reply]

Pretty sure MSGJ came here because the error occurred in Module:TwitterSnowflake, whose talk redirects here, which is still used in {{cite tweet}}. Nardog (talk) 00:47, 18 February 2023 (UTC)[reply]

Thank you — Martin (MSGJ · talk) 07:19, 18 February 2023 (UTC)[reply]

The TwitterSnowflake module appears to fail with a script error on invalid dates. Here's one I found in the wild:

{{Cite tweet|number=1055907442213580800|user=conangray|title=my middle name is "lee" so all i gotta do is name my child "fam"|author=Conan Gray|date=October 98, 2098}}

Can it be improved to display a real error message and a {{Cite tweet}} error-tracking category instead? – Jonesey95 (talk) 14:19, 23 May 2023 (UTC)[reply]