sm00th / bitlbee-discord

Bitlbee plugin for Discord (http://discordapp.com)
GNU General Public License v2.0
291 stars 27 forks source link

Add timestamp support #153

Closed Alcaro closed 6 years ago

Alcaro commented 6 years ago

Improves #152, but I wouldn't consider it fully fixed until bitlbee/bitlbee#98 (or equivalent) is done. Your choice if it's good enough that #152 can be closed.

strptime isn't part of the C standard library, but it is part of POSIX; since manual mentions 'sudo make install', I suspect non-Unix isn't supported. If that's incorrect, I can check if GLib contains a date parser, we already have a dependency on that.

Finally, bitlbee dev docs suck.

dequis commented 6 years ago

Yeah sending timestamps like this from the prpl is a prerequisite for server-time anyway.

bitlbee dev docs suck

What sort of docs were you looking for?

Alcaro commented 6 years ago

I've had similar issues several times. This time, it was whether timestamp 0 in imcb_chat_msg is 'don't know', or jan 1, 1970 and timestamps are off by default; every time, I've had to try it, or dig through the bitlbee source code, to find the answer.

And every time, I haven't been able to find any docs at all. Googling imcb_chat_msg just gives me random patches and source code, and other non-documentation. Looking at the bitlbee homepage contains nothing useful either; /usr/include/bitlbee/ lists which functions and structs exist, but nothing about special cases like that, and if I'm not modifying something where the relevant parameters already exist, it's hard to find which function is relevant.

Do the docs even exist? If yes, where, and why can neither I nor Google find them?

Alcaro commented 6 years ago

Yeah, I agree those variable names suck.

However, I'm not convinced GTimeVal is an improvement. The docs don't specify epoch nor timezone handling anywhere (that struct looks more designed for relative times); however, docs do say

GLib is attempting to unify around the use of 64bit integers to represent microsecond-precision time. As such, this type will be removed from a future version of GLib.

However, g_date_time_new_from_iso8601 seems like a sensible replacement. (Though it was somewhat irritating to find.)

Alcaro commented 6 years ago

...crap, g_date_time_new_from_iso8601 requires GLib 2.56, my server only has 2.50.

Guess I don't have much of a choice other than g_time_val_from_iso8601. Seems to use Unix epoch, I'll just assume it stays that way, despite lack of promises in the docs.

sm00th commented 6 years ago

Thank you.