Thanks, SOCF!
I'm in the process of checking timestamps for the entire data in https://qanon.pub/data/json/posts.json
Will have a list of how that compares to the 3-timezone HTML later today, and will post it here.
Is that the data you're using for your work?
Looks like the microphone on the speaker's podium.
Can also be seen in the colored pics anons posted last night.
>Is that the data you're using for your work?
Apologies, I've read over the fact you've answered the question already.
>Anyone have another json (or similar) source for drops with the correct times?
As mentioned, I'm using the 3-timezone HTML (link to mega.nz up in the dough).
For pure data analysis, the "HTMLonly" version is sufficient, and from what I've found so far, they simply copy/extract the original HTML source.
Thus, there shouldn't be any errors in timestamps – at least haven't found any so far.
As I understand it, the mapping of calendar days to hours & minutes came from Q replying "Clock started - 10 days" upon an anon's question "What happened on 12/7?"
It is one of the times also shown in the QClockView program (Q-Calendar Time), and a number of stronger than weak indications were found that this indeed might be a valid concept. Would have to look them up, but am pretty sure other clockfags around here remember some of those.
Since 2017-12-07 this "Calendar Time" progressed one min/day, with 12 "calendar hours" elapsed by 2018-11-27.
It is not a concept I personally rely on too much, but due to abovementioned observations/coincidences I've left it in the program for the time being.
Here are the results of qanon.pub's json vs. the 3-TimeZone HTML.
The json file also has posts by anons which were quoted by anons which were quoted by Q giving me a number of alerts which I had to verify and dismiss/ignore manually.
Below is the list, QPostNums followed by an asterisk (*) are posts by anons quoted by Q.
Haven't done the reverse check yet (3-Timezone HTML vs. json) and will do that now just to be sure and exclude errors I might have made.
QPost UnixTime PostNo BRD Time (EST,qanon.pub) vs. Time (EST,3-TZ HTML) Time (UTC,3-TZ HTML)
[3537] 1575305032 00000018 /pd/ 02-Dec-2019 11:43:52 vs. 02-Dec-2019 12:43:52 02-Dec-2019 17:43:52
[0473] 1515219283 00252070 /cb/ 06-Jan-2018 01:14:43 vs. 05-Jan-2018 19:14:43 06-Jan-2018 00:14:43
[0472] 1515217767 00251826 /cb/ 06-Jan-2018 00:49:27 vs. 05-Jan-2018 18:49:27 05-Jan-2018 23:49:27
[0471] 1515217167 00251731 /cb/ 06-Jan-2018 00:39:27 vs. 05-Jan-2018 18:39:27 05-Jan-2018 23:39:27
[0471]* 1515216828 00251685 /cb/ 06-Jan-2018 00:33:48 vs. 05-Jan-2018 18:33:48 05-Jan-2018 23:33:48
[0470] 1515216992 00251705 /cb/ 06-Jan-2018 00:36:32 vs. 05-Jan-2018 18:36:32 05-Jan-2018 23:36:32
[0470]* 1515216714 00251666 /cb/ 06-Jan-2018 00:31:54 vs. 05-Jan-2018 18:31:54 05-Jan-2018 23:31:54
[0469] 1515216498 00251626 /cb/ 06-Jan-2018 00:28:18 vs. 05-Jan-2018 18:28:18 05-Jan-2018 23:28:18
[0466] 1515191798 00248746 /cb/ 05-Jan-2018 17:36:38 vs. 05-Jan-2018 11:36:38 05-Jan-2018 16:36:38
[0465] 1515190727 00248629 /cb/ 05-Jan-2018 17:18:47 vs. 05-Jan-2018 11:18:47 05-Jan-2018 16:18:47
[0464] 1515190343 00248590 /cb/ 05-Jan-2018 17:12:23 vs. 05-Jan-2018 11:12:23 05-Jan-2018 16:12:23
[0399]* 1513870871 00139380 /cb/ 21-Dec-2017 10:41:11 vs. 21-Dec-2017 10:52:48 21-Dec-2017 15:52:48
[0233] 1511641718 10956374 /8p/ 25-Nov-2017 15:28:38 vs. 26-Nov-2017 00:28:38 26-Nov-2017 05:28:38
[0230] 1511636085 10956085 /4p/ 25-Nov-2017 13:54:45 vs. 25-Nov-2017 22:54:45 26-Nov-2017 03:54:45
No thanks. Last time (which is a while ago though) I checked TextAnon's data it had errors as well.
Did the reverse check, and decided to never look at the json file again. Kek!
All posts listed above have wrong timestamps on qmap.pub as well, but as pointed out in >>7880875, there are more timestamp errors on qmap.pub (maybe good I have no json file from qmap.pub. kek!).
No bad feelings at all towards either of the two sites much less their admins – I'm saying this from the perspective of a datafag with quite some experience in handling/analyzing different data & formats.
To give one example: some timestamps appear as much as 15 (1512844084), 14 (1536616013) or 13 (1513733171, 1550428126) times in the json file. Haven't analyzed the reasons for it.
In addition to the three posts made by anons with wrong timestamps listed above, there are 86 posts made by anons & quoted by Q that are missing from the json file.
Not listing those here, but I put them on pastebin: https://pastebin.com/mgfi6Uqg
>3-TimeZone HTML
Just as a reminder, the HTML has 6 Q posts not listed on qmap.pub/qanon.pub, and 2 Q posts which are only listed as a quote (i.e. w/o their own number, quoted with another Q post).
>sounds like a giant shit show
Kek! Well I wouldn't put it quite so drastic.
So far I'm really happy with the HTML format, and the QClockView works fine with it as well. It has been left in the original format (HTML), and I could re-format it into any other format I find useful with a couple of lines of bash.
But yes, different reasons I'd think, and for some people it doesn't even matter that they work with wrong timestamps.
As a clockfag of course it does matter …. but I'd be called a shill if I posted messages to admins of qmap.pub & qanon.pub every bread, reminding them they've got errors in their data ….. ;)
There's a small additon to make to the 227 tweets/posts between 2017-10-28 & 2017-11-24: It only holds when POTUS' deleted tweets are not counted.
Have had a look today at sequences of days with the sum of Q posts equaling the sum of POTUS tweets within some timespan, and found quite a number of them (with timespans >= 2 days and timestamps in EST).
The sequence starting at 2017-10-28 has a third member: By end of Mar 13th 2018 (137 days) there were 944 Q Posts & POTUS tweets.
Found 250 such sequences, the longest spanning 195 days starting Nov 6th 2017. As mentioned, removed deleted tweets & also those 8 Q Posts which are not separately listed on qanon.pub/qmap.pub.
By the way, there was a new record number of tweets per day set 2 days ago: 142 tweets on 01/22.
>Have you tried https://qagg.news yet?
Never heard of it, just gave it a quick look.
They have a "download Q Drops" option and I superficially checked the downloaded data.
It would appear they use the same data as qmap.pub (different from qanon.pub) but do not provide timestamps in UTC (i.e. unixseconds). Instead their timestamps in the downloaded HTML seem to be Central time (i.e. incl. DST).
Quick check of the first members of above list >>7887517 shows the same errors.
I think their timestamps have DST internally (not just in the download but in thier actual original core data), which introduces errors on my screen, as my system is set to UTC default.
So for example, https://qagg.news/read/?postnumber=1471 appears as 06/12/18 18:38:05 on my screen,
but actually is 06/12/18 17:38:05 UTC.
When I click "Force times to EST" in their options I get: 06/12/18 13:38:05
instead of the actual EST of 06/12/18 12:38:05
Even with the tools they offer (deltas etc), I have to ask what those are worth if the underlying data is incorrect ….
>to be the most powerful research tool thus far
As for tools, and depending if your are using linux, it's not too hard to collect/provide a set of tools that works with the 3-timezone HTML.
Which tools are you looking for or you'd like to have that QClockView doesn't provide but can be found on qagg.news?
Got it. Well, can't do much about QAGG, but as a datafag I simply know that there's only one kind of timestamps to use when times are important, and those are UTC.
All continuous, no shifts, no sudden jumps from "01:59:59 to 01:00:00 etc….
Also, when providing data, for me it's a constant process of checking & cross-checking over and over again.
So I'm a bit disappointed there's so many errors/inconsistencies on all of these sites.
On the other hand, I'm not a fan of "online" when it comes to data. The correct way is to download it and store/work offline, and then double- and/or cross-check.
As for simple things (such as deltas b/w posts), I could, if anyone's interested, post a simple one-liner on the command line that computes these from unix timestamps in the 3-tz html (sed, awk & grep are really useful!).
>easy fit-to-screen option in qcv
Will have that included most likely by this weekend.
>other online resources for q posts
There was this remarkable piece of clockwork posted last night in the general.
Can't figure out which source they used in the pic. Maybe some other anon is familiar with the origins of this format of q posts.
Thanks! Would be curious to see if you get similar results as I did – found a rather surprising number of sequences with same post/tweet count.
Had made a quick run at it as well last night, but w/o double checking results.
Used my own dataset of tweets (above tweets-pdf is one result of it), which I could share if needed and the 3-tz html.
In case you hadn't noticed yet, see above in >>7906649 for a short summary.
>it does align with some other things I've been working on
Sounds good. I simply posted it here in my role as the "secretary" (IANYFS … kek!), since it caught my eye.
It also made me list :[MM]:[SS] timestamps and count their number of occurrence.
Leaders are: 6 posts for :41:11, :43:38, :50:59 & :55:52
But please book that under rather useless clockfagging. Kek!
There's a new version of QClockView up on mega.nz.
It does have a "Fit to Window" function included (shortcut Ctrl+W, see pic) and some other smaller changes.
As always, feedback as to if it works as intended and/or requests regarding functionality/usage are highly appreciated.
o7