zlacker

[parent] [thread] 18 comments
1. sargun+(OP)[view] [source] 2020-12-30 23:09:17
Unfortunately, I do not have the chops to debate against this, but the political ramifications would be immense. The bet (https://www.rootclaim.com/rootclaim_challenge) requires that (a) you have $100k (b) are able to successfully debate it.

I won't put $100k against this, but I'll put $10k against it, because "the truth" is worth it. I'll pool $10k into a $100k stake behind a debate team that can debate this (and validate that this is actually refutable). This is valid until 2021-03-01.

replies(3): >>purple+x2 >>ikeboy+Y5 >>Torwal+u7
2. purple+x2[view] [source] 2020-12-30 23:26:36
>>sargun+(OP)
why that date
replies(1): >>consum+d6
3. ikeboy+Y5[view] [source] 2020-12-30 23:50:58
>>sargun+(OP)
Trevor Bedford may be interested - he had a good thread all the way back in February https://twitter.com/trvrb/status/1230634136102064128

If someone organizes something credible I'd also be in for 10k.

However, I suspect root claim wouldn't go through with it but would just update their model to incorporate more information. They hint at that possibility on their site.

◧◩
4. consum+d6[view] [source] [discussion] 2020-12-30 23:52:17
>>purple+x2
Not gp, but to me it seems common and smart to put an expiration date on all financial offers.

That's the simplest explanation at least. This rootclaim.com process is new to me, there could certainly be other explanations.

Kudos to purplecats for making that offer as well, assuming this whole thing is on the up and up.

edit: below was my post when it was first upvoted, prior to edit.

> Not gp, but to me it seems smart and common to put an expiration date on financial offers.

> Kudos to purplecats for making that offer as well.

replies(2): >>phkahl+io >>sargun+1r
5. Torwal+u7[view] [source] 2020-12-31 00:01:23
>>sargun+(OP)
Please clarify your date format. Is that 1st of March or the day before 4th of January? According to my European sentiment it's the 3rd of January, is that correct?
replies(2): >>rcoves+T9 >>avmich+4a
◧◩
6. rcoves+T9[view] [source] [discussion] 2020-12-31 00:21:16
>>Torwal+u7
There are many ambiguous date formats, but this is not one of them. Four digits, delimiter, two digits, delimiter, two digits always means year, month, day, no matter where you are in the world[0]. Well, except in Kazakhstan, but only when writing in the Khazakh language.

0. https://en.wikipedia.org/wiki/Date_format_by_country

replies(1): >>cyode+va
◧◩
7. avmich+4a[view] [source] [discussion] 2020-12-31 00:22:27
>>Torwal+u7
Most often I see this as an example of ISO 8061 date, https://www.iso.org/iso-8601-date-and-time-format.html .

"Looking for an unambiguous calendar-and-clock format that is internationally understood? It’s time for ISO 8601."

"ISO 8601 tackles this uncertainty by setting out an internationally agreed way to represent dates:

YYYY-MM-DD

For example, September 27, 2012 is represented as 2012-09-27."

replies(2): >>titzer+Ch >>sargun+or
◧◩◪
8. cyode+va[view] [source] [discussion] 2020-12-31 00:26:01
>>rcoves+T9
> There are many ambiguous date formats, but this is not one of them.

The comment you've replied to is a counterexample to this claim.

replies(2): >>rcoves+8c >>sjwrig+2h
◧◩◪◨
9. rcoves+8c[view] [source] [discussion] 2020-12-31 00:39:12
>>cyode+va
That's true, but it takes more than one example of confusion to justify the label "ambiguous." Otherwise the label would have no meaning; it could be applied to anything that had ever caused anybody confusion, which is everything.

For example, the meaning of the word "ambiguous" is not ambiguous. If somebody were to ask what the word meant because they did not know the definition, it wouldn't make the word's meaning ambiguous. It would make that person uninformed.

◧◩◪◨
10. sjwrig+2h[view] [source] [discussion] 2020-12-31 01:22:44
>>cyode+va
Confusion due to a lack of awareness of an unambiguous standard is not synonymous with ambiguity.
◧◩◪
11. titzer+Ch[view] [source] [discussion] 2020-12-31 01:27:47
>>avmich+4a
Yes, yes, yes, please use ISO 8601! Big-endian is the only rational way to sort dates and it combines nicely with time-of-day as well.
replies(1): >>sargun+kB
◧◩◪
12. phkahl+io[view] [source] [discussion] 2020-12-31 02:26:15
>>consum+d6
>> it seems common and smart to put an expiration date on all financial offers.

And all contractual obligations including thing like NDAs. Maybe it's a number of years, but never enter one for a lifetime. Ever.

◧◩◪
13. sargun+1r[view] [source] [discussion] 2020-12-31 02:55:40
>>consum+d6
It’s to avoid wasting time, to create a sense of urgency, and to avoid putting myself in an awkward situation where I have to say no due to changed circumstances.
replies(1): >>purple+Y81
◧◩◪
14. sargun+or[view] [source] [discussion] 2020-12-31 02:58:48
>>avmich+4a
Yep. Although I don’t use ISO8601 for time stamps when communicating online (for 2021-03-01T00:00Z is more confusing to me than 2021-03-01 16:00 PST8PDT), it’s easier to use for dates when discussing in an online forum where people may be from outside of the US.
replies(1): >>grzm+Wr
◧◩◪◨
15. grzm+Wr[view] [source] [discussion] 2020-12-31 03:05:12
>>sargun+or
nit: ISO8601 permits offsets: you don't need to always use UTC/Z. 2021-03-01T16:00-0800 works just fine.
replies(1): >>sargun+gB
◧◩◪◨⬒
16. sargun+gB[view] [source] [discussion] 2020-12-31 04:56:36
>>grzm+Wr
I can’t remember the time zone offset between PST and PDT, and when the switch happens.
replies(1): >>grzm+sB
◧◩◪◨
17. sargun+kB[view] [source] [discussion] 2020-12-31 04:57:41
>>titzer+Ch
Big endian is also much easier to read as someone who reads from left to right.
◧◩◪◨⬒⬓
18. grzm+sB[view] [source] [discussion] 2020-12-31 04:58:52
>>sargun+gB
Well, I'm with you there :) I'm all for getting rid of twice-yearly (biannual? semi-annual? perhaps hemi-annual?) offset changes!
◧◩◪◨
19. purple+Y81[view] [source] [discussion] 2020-12-31 11:46:42
>>sargun+1r
makes sense but what heuristic did you use to come up with that specific date/duration?
[go to top]