# I am the Watcher. I am your guide through this vast new twtiverse.
# 
# Usage:
#     https://watcher.sour.is/api/plain/users              View list of users and latest twt date.
#     https://watcher.sour.is/api/plain/twt                View all twts.
#     https://watcher.sour.is/api/plain/mentions?uri=:uri  View all mentions for uri.
#     https://watcher.sour.is/api/plain/conv/:hash         View all twts for a conversation subject.
# 
# Options:
#     uri     Filter to show a specific users twts.
#     offset  Start index for quey.
#     limit   Count of items to return (going back in time).
# 
# twt range = 1 7
# self = https://watcher.sour.is/conv/q67lh7a
To all people writing software: Please, always include the *time zone* when showing dates/times, *especially* in log files. It’s almost always the right thing to do and can save your users so much headache during debugging.
To all people writing software: Please, always include the *time zone* when showing dates/times, *especially* in log files. It’s almost always the right thing to do and can save your users so much headache during debugging.
To all people writing software: Please, always include the *time zone* when showing dates/times, *especially* in log files. It’s almost always the right thing to do and can save your users so much headache during debugging.
@movq I fully support this! In the past I had to analyze and correlate events in log files and it was very hard without the timezones. One was in UTC and the other in UTC+X. Bonus if customer-reported times for the inquiry were in UTC+Y. Of course I always forgot until next time which log used which timezone. So I had to figure it out again and again. What a giant waste of time. :-(

However, that's nothing compared to my current project. Here, I must deal with logs where the timezone is somehow part of the logs (I think), but the log viewer can be configured to display timestamps in a certain other timezone. Also, timestamps are generated by the logging service when receiving the event, not when the application actually produces it. Don't ask. Often, timestamps are just plain wrong and not useable. Luckily, the uptime counter is included as well, which seems to be accurate from what we've seen so far. It's by far the most horrible logging system I've ever come across. It gets extra funny when bug reports contain references to the timestamps in any other than the default timezone of the viewer. Of course reporters do not tell you. It's a world-wide project, so chances are that timezones are all over the place. Unbe-fucking-leavable.
@lyse Baaaaaaaaaaaaaaaaaaaaaaaaah! 🤣 What a mess.
@lyse Baaaaaaaaaaaaaaaaaaaaaaaaah! 🤣 What a mess.
@lyse Baaaaaaaaaaaaaaaaaaaaaaaaah! 🤣 What a mess.