[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-relays] Simplifying ExoneraTor



> 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