Talk:2594: Consensus Time
Less than a day should be enough time for a team of people to notice and override the trolls' attempt to game the system. Unless the trolls decide to push the button right before midnight. --188.8.131.52 23:11, 16 March 2022 (UTC)
- Presupposes that an executive decision that "oh, that was just sabotage, we can ignore all those 'votes'" by an oversight panel is deemed ok to occasionally enforce. As with actual election votes, that shouldn't be taken lightly (for fear of top-down skewing of the actual sincere wish of those casting their opinions).
- As it's a median (in itself a good idea, as there's no reason to cast very extreme outliers — it doesn't do anything more to the result than a barely marginal outlier) all you need to do is ask enough people (in excess of any counter-aiming participation, if there's a fight over it) to merely adjust their 'feeling' to half an hour later (or earlier, if that's your aim) than they normally would.
- Added to the 'natural' variation in feeling (spread statistically amongst your participating group) it would be practically impossible to decide that a distinct tapering-lump of results exists, to possibly disqualify. Whereas if results show clear 'lumps' hours apart (e.g. around 3AM and/or 9PM, as well as the standard bunch around the 'honest' opinion point), there might be a case to officially intervene. Or at least officially review the procedure. 184.108.40.206 09:14, 17 March 2022 (UTC)
- It's basically Wiki-Time, the same principles apply as a Wiki... and Wikis are always 100% accrate, rite? --192·168·0·1 (talk) 18:42, 17 March 2022 (UTC)
Probably a reference to the Senate DST thing220.127.116.11 17:46, 16 March 2022 (UTC)
I feel like this could supersede time-zones as well, by weighting reports by relative longitude, so you could have a kind of continuous change in time as you travel. I'm sure this wouldn't cause any problems at all, since every single computer would effectively be in its own mini time-zone, with its clock going at a slightly different speed, and both current time and speed of time would vary continuously with position.18.104.22.168 17:53, 16 March 2022 (UTC)
My take on this is that Midnight is a fixed point, it's always at the same time, and the day compresses and expands around it based on the median 9AM location. So, some days will have long hours in the morning, then compressed hours in the afternoon and evening. --22.214.171.124 20:37, 16 March 2022 (UTC)
The sociologist in me wants to see this... The computer scientist in me could not be reached for comment and only mumbled something about "checking stock in the bomb shelter" 126.96.36.199
Hmm... Does this probably mean 9AM today could theoretically be after 9AM tomorrow in some cases!? Talk about a new approach to time travel. 188.8.131.52 05:12, 17 March 2022 (UTC)
Working example: https://matthewminer.name/projects/consensus-time/ --184.108.40.206 20:47, 18 March 2022 (UTC)
I've often thought the answer to the arguments about daylight saving time could be solved by going back to something like the old Canonical Hours with the period from sunrise to sunset divided into 12 hours, with short hours in winter and longer ones in summer. Incidentally, in the late sixties, an experiment was tried in the UK to keep the country on daylight saving all year round, called British Standard Time. I remember going to school in the north of England in December and it was still dark to well past nine o'clock in the morning. It apparently reduced road deaths, but it was abandoned after three years. --220.127.116.11 09:09, 17 March 2022 (UTC)
Re. "the next vote would occur sooner or later respectively": This doesn't make sense - by definition, the vote takes place at no fixed time. Everybody votes at different times, depending on when they feel like it's 9am. They could, if they wished, do this capriciously, with no relation at all to the previous day's vote. One possible outcome of this is that the consensus view could drift so far from that of some individual views that it becomes impossible to determine which 'day' they're voting in respect of, and therefore which vote they should be counted in.18.104.22.168 11:25, 17 March 2022 (UTC)
- I see your point. If I was writing it, I'd suggest one of three alternatives.
- The time that an otherwise consistent (possibly even 'accurate') voter votes is at variable times according to the Consensus Clock.
- What it really means is that the votes are actioned (or processed, but see below) at Consensus Midnight (close-of-votes) which is going to usually be earlier/later than 24-hours after the prior C.M. point.
- During the period of longer (or shorter) hours, for the Consensus adjustment, the vote that comes in three Consensus Hours before that day's Consensus 9AM will not actually be three 'real' hours before that point, and there is no indication that it will be back-adjusted, in case the Consensus Median Vote asked for 15 minutes earlier but might appear to be (say) 10 minutes earlier. (A vote that is deemed Consensus Median and 15 minutes later will always be intrinsically 15 minutes later.)
- But I don't think there'll ever be a problem deciding which day a vote is effective for (though it might be different from intention, for the more inattentive voters). My proposed implementation would be to assume a cut-off at (or maybe slightly before, depending upon overheads) C.M., with all votes now either held off or handed straight over to the next day's vote as very-early votes for the next 9AM rather than very-(very-very-)late votes for the one now being acted upon.
- A simple method that saves end-of-day time to process involves a chronological-queue of incoming votes. For every odd-numbered vote added to the tail of the queue, from the 3rd one onwards, a single recorded vote (the current earliest) is shifted off the head of the queue (to be recorded/archived, maybe, but no longer relevent to the result we will calculate).
- At the moment of tallying, the head of the queue has your median-vote. The next one waiting to be shifted, if it's an odd-length, the mid-point of that with the next one on if the queue is even-length. (If I've described/imagined it correctly!)
- This immediately sets the time-factor used to expand/contract the hours from 00:00 to 09:00 in the Consensus Clock to get 9AM to match the Consensus Median Plus 24 Hours.
- Problems with lag/latency of incoming votes (chronologically confirmed, at source, but late to be processed centrally) would be most important with those immediately around the precisely defined Median, when sheer weight of opinion suggests that it'll be the most busy, but there should be enough idle-capacity to insert or shuffle items into the right bit of queue before the Midnight point. Or maintain sub-lists (5 minute slots?) that are maintained and finalised seperately and then their number of entries reported as a simple digest so that the system knows that "the nth point of the mth array", and maybe the n+1th, or the first in the m+1th (if needed), is/are to be plucked out at Midnight and looked at.
- It really won't matter if a million votes come in at 23:59, so long as they are counted and have been at least balanced by a million earlier-votes from 00:00 onwards. But if valid and acceptable but very late votes filter through after a preliminary decision has already been made based upon a now pre-Median time-vote timing, the new (true) Median can be established within the first few minutes (or probably seconds, or even microseconds!) of the adjusted-hours and the adjustment-Rate simply re-adjusted accordingly to meet whatever the revised Consensus is (seconds later? minutes later, at a push?).
- It could not push the next 9AM beyond 24 hours from the vote-period's closing Midnight, and likely won't push it beyond the prior idea of what the Midnight the upcoming day would originally have, without serious mass-action to break the system.
- An example of deliberate breaking could be by coordinating everyone to seed a few heavily premature votes (so the next Midnight is sent close to 15 real-hours after the vote-close one, very compressed 0:00->09:00 upon the clocks) then virtually nothing until everyone else quite deliberately votes at a confirmable moment of 23:59:59 (or as close as feasible, without being next-day votes, whilst jamming the queue-mechanism and forcing delayed evaluation) to force the rapidly-compressed clocks to switch over to a snail-paced rate to compensate...
- ...But that kind of coordinated civil-disruption wouldn't be suddenly conjoured out of nowhere. I would expect that there'd be plenty of forewarning that any particular disruptive strategy is being considered (or experimented with), and it also needs (almost) everyone to be striving to force the exact same scenario with easily detected coordination of instructions. Heavily outnumbering both honest-voters and those dishonest-voters contrarily inclined. Otherwise the effect is minimal, or even practically ineffective. 22.214.171.124 21:39, 17 March 2022 (UTC)
Of course, before mechanical clocks, hours varied across the year. With 12 short hours each day, and long ones over night in winter and 12 long ones in summer, with shorter hours overnight. Arachrah (talk) 21:31, 17 March 2022 (UTC)
The total day length would remain the same in this proposal. That means that the length of the hours (both before and after 9AM) would vary. The reference to the weekly cycle seems to refer to the fact that people tend to sleep in during the weekends. Thus, on Saturday and Sunday the buttons would be pressed later, and consequently 9AM would be relatively late on Sundays and Mondays. What (if any) effects there would be on other weekdays is unclear to me, which makes it an interesting experiment to conduct in someone else's country. 126.96.36.199 10:13, 19 March 2022 (UTC)
- "The total day length would remain the same in this proposal." - I'm not sure about that. If it had marked 'Shorter Hours' for the latter ⅝ths of the day, I'd agree. The drawn hour-ticks might indeed look (possibly measure) differently-spaced between each example of 9AM to Midnight. But I'm not sure that isn't just an illustrative foible. The assertion that midnights on that retro-subjective scale are locked to the objective (solar? meridean-gap wide?) midnights is far more obvious in its ommission. 188.8.131.52 15:14, 19 March 2022 (UTC)
My personal solution is for my clock noon to be identical to solar noon, at my present location, and for clock midnight to be halfway between solar noon of the previous and next days. That may mess up everyone else, but I'll be satisfied. (I hate early sunsets during the winter here.) These Are Not The Comments You Are Looking For (talk) 20:27, 21 March 2022 (UTC)
Ironic that the IP editor who finally removed the Incomplete-tag (in this and apparently many other articles) then went on to further modify the page. Not that I'm a fan of perpetual-Incompleteness, but I just wanted to note the arse-wise editing priority. At least make the change you want and then (in the same edit-submission or a follow-up one once you're sure) then make it officially Complete. Not that I expect that IP to notice this assessment of their actions, but it makes me feel better to share my rather predictable thoughts on this... 184.108.40.206 21:52, 24 August 2022 (UTC)