> On 5 Jul 2015, at 23:26 , Karsten Loesing <karsten@xxxxxxxxxxxxxx> wrote: > > >>> Also, there seems to be 24 rows with white background, then 24 > >>> with light grey bg. If the search returns eg. 30 results, then > >>> only the last 6 would be in grey, and users could potentially > >>> think there's something special about those. I'd use a much > >>> smaller number, eg. 5 at most, so it's obvious that the > >>> background is just there for aesthetic reasons. > >> > >> Ah, the highlighted rows contain results for the searched date, > >> whereas the other rows are for the previous and next date. The > >> idea is to always search +/- 1 day in order not to rely on users > >> figuring out timezones correctly. Maybe the highlighting is too > >> implicit though. I'll leave it out. It's not worth explaining > >> to users what the highlighting is about, and it's particularly > >> not worth confusing users with it. > > > > "The two extreme time zones on Earth (both in the mid Pacific) > > differ by 26 hours." > > https://en.wikipedia.org/wiki/List_of_UTC_time_offsets > > > > So can we possibly change this to +/- 26 hours? (or, perhaps, 30 > > hours, just in case some region adjusts its timezone another hour > > or two out?) > > > > For the sake of those in Kiribati, Samoa, Tonga and the eastern > > New Zealand islands on one side, and the US Minor Outlying Islands > > on the other. > > But no timezone can be more than -12 or +14 hours away from UTC, so I > think we're good by including the previous and next 24 hours of any > given date. That being said, I'm not good at timezones, so it's quite > possible that my math is wrong. When you wrote +/- 24 hours, I assumed a 48 hour period centred on the current UTC time, not a 72 hour period centred on midday on the current UTC date. (My mistake, 72 hours is what you describe in the interface.) In more detail, UTC -12/+14 can't ever fall outside date(UTC) -24/+48: * date() (or floor(), if you prefer) will only ever subtract up to 24 hours, therefore * date(UTC) -24/+48 ranges from UTC -24/+48 to UTC -48/+24, therefore * date(UTC) -24/+48 always lies within UTC -24/+24, and * UTC -12/+14 always lies within UTC -24/+24, so * UTC -12/+14 always lies within date(UTC) -24/+48. Of course, people can always mess up their timezone conversions, assume the local/UTC time in the logs is correct, or be uncertain about when an event actually happened. There's not much we can do about that. But guaranteed +/- 10 hour fuzzy matching in any results from any timezone is a pretty good start. (And there's even greater leeway if your timezone is close to UTC, or the time you're searching for is close to midday UTC.) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com pgp ABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays