[01:39:26] @vrandecic another proposal for Volunteers Corner function: Gregorian calendar date to list of English (and possibly other languages) Lexemes [01:39:27] Today (UTC) -> [L711, L20, L324483, L20, L332] or similar [01:39:28] This one will likely be quite challenging. [01:59:57] One for each of the components would be easier to write first. Eg English_lexeme_for_Gregorian_month. In future that may be achieved via a Wikidata item reference, but for now it would be a good complement to the enumerated type. (re @Feeglgeef: @vrandecic another proposal for Volunteers Corner function: Gregorian calendar date to list of English (and possibly other [01:59:57] langu...) [02:00:20] Yeaj (re @Toby: One for each of the components would be easier to write first. Eg English_lexeme_for_Gregorian_month. In future that may be achi...) [02:09:21] Toby can you comment on [[Wikifunctions:Type proposals/Gregorian calendar date]]? [06:30:14] The sooner we have consent, the sooner we'll get the type. Then again we're not in any particular hurry, it's holiday season, I'll be traveling, etc (re @Al: Thanks, Denny. I’m not too bothered about JavaScript but I’m really struggling to feel comfortable with a three-key solution for...) [07:08:26] I'm also a little too busy to rush it. But I have been thinking about it a bit. Am I right that nobody contests the underlying type being date + year? That makes sense to me too. As I understand the issue is just how many keys to convert into each program language's code? It seems like a trade-off between (programmer ease & runtime speed) vs (coverage of millennia and [07:08:26] purity of [07:08:27] correctness). (re @Feeglgeef: Toby can you comment on [[Wikifunctions:Type proposals/Gregorian calendar date]]?) [07:10:19] But it was eye-opening to see how many problems we had to fix when an almost-new Type was slightly changed (to include Lexeme senses). So I am somewhat wary of committing too early to something that could be non-optimal. [07:40:11] Usually I care more about accuracy than speed. But in this case I think we are likely to call these functions quite a lot for Wikipedias, and in 99.9999999999999999% of the real usage cases, the JS Date range will work. And JS is usually our fastest language. So I'm a little tempted by the pure date object for JS. [07:43:32] I understand that feeling. One could argue that beyond the 100000 AD and before 100000 BC the Gregorian proleptic calendar doesn't even make real sense. [07:43:33] On the other hand, I am not worried about speed at this point. I expect to see significant better handling of CPU cost as we move forward, and I do like the idea of doing it "right". I am also torn. [07:46:39] Then I wonder whether we can use our multi-program-language facility to our advantage. We could do python "right", but JS "fast". Then some functions would suit one or the other, and overall we'd always win. But maybe this makes us disorganised and overly-complex. [07:53:53] I find it hard to estimate whether "significant" will be enough. Even if all our executions become 1000 times faster, in the long run we may be trying to answer millions of function calls per second. By the time we are the size of Wikidata, it would be nice to prevent issues like needing to "split the graph". Imagine people cursing us 10 years down the track for making [07:53:53] a call t [07:53:54] hat costs an extra 50% on every date function, then arguing about how to "split the Date Type". (re @vrandecic: I understand that feeling. One could argue that beyond the 100000 AD and before 100000 BC the Gregorian proleptic calendar doesn...) [07:56:28] "beyond the 100000 AD and before 100000 BC" I didn't understand that in the proposal actually. Did you just give away 300,000 years? Can't we go from -250k to +250k? [07:57:56] If it's "just" a 50% difference, then either will still have a "split the graph" problem. I think it need to be 2-3 orders of magnitude of difference to "save" us from problems of that kind. (re @Toby: I find it hard to estimate whether "significant" will be enough. Even if all our executions become 1000 times faster, in the lo...) [07:58:59] Yeah, I did. I was wondering to use a more natural limit, in order to not be so obviousy tied to the JavaScript implementation. I am also fine with 250000AD and 250000BC as the limits. But I don't want the exact limits of JavaScript! (re @Toby: "beyond the 100000 AD and before 100000 BC" I didn't understand that in the proposal actually. Did you just give away [07:58:59] 300,000 ye...) [08:02:33] I have a slightly different view on this: originally, I wasn't for a SPARQL endpoint at all, because I was expecting it to lead to scalability issues. And the SPARQL endpoint was introduced after my tenure as Wikidata lead by Lydia. And in hindsight I think she made the right call. Did we run into scalability issues now? Yes. Would Wikidata have ever grown like [08:02:33] this if Lydia didn [08:02:34] 't have made the call? I have my doubts. I am looking forward for Wikifunctions having their version of the split the graph problem, because that means Wikifunctions has become very succesful. (re @Toby: I find it hard to estimate whether "significant" will be enough. Even if all our executions become 1000 times faster, in the lo...) [08:05:20] Okay, perhaps I was being over-dramatic. So I'll be over-over-dramatic instead: Imagine it's "just" a 50% difference, and our AI avatars start scrutinising the carbon footprint of WMF who have just bought 50% more compute because we cared less about CO2 than we did about which date would be a Tuesday 300,000 years after climate-driven civilisational collapse. (re @Jan [08:05:20] ainali: If [08:05:21] it's "just" a 50% difference, then either will still have a "split the graph" problem. I think it need to be 2-3 orders of ma...) [08:07:33] My loose analogy was in no way meant to criticize anyone. I love SPARQL. I love the WDQS. I love Wikidata being big, and I want it to be able to grow by at least 3 more orders of magnitude. (re @vrandecic: I have a slightly different view on this: originally, I wasn't for a SPARQL endpoint at all, because I was expecting it to lead ...) [08:08:02] Just to give a few ideas why I am not so concerned about compute efficiency of the current system: I am quite confident that as we grow we will for example be able to package function implementations as WASM binaries which then can be executed on other hardware than WMFs server. I also think that the current architecture, where compositions are being run by [08:08:02] individually evaluatin [08:08:03] g the components can be turned into a system where we compile a composition into a single evaluation package that can then be run in a single evaluation step, drastically reducing network overhead. [08:12:57] And I am not arguing for one side or the other. I think I would be fine with the 3 key solution for Python, and either the 3 key solution for JavaScript or the pure date object for JavaScript. [08:12:57] But also, I am not sure how much benefit we will derive from JavaScript's date object: it doesn't have *that* many capabilities, to be fair. [08:13:51] Even if the difference in the date functions are 50%, I find it unlikely that the amount of date related function calls in Wikifunctions would need WMF to buy 50% more compute in total. I think it is much more likely that the AI avatars will be upset with other stuff happening in our ecosystem. (re @Toby: Okay, perhaps I was being over-dramatic. So I'll be [08:13:51] over-over-dramatic inst [08:13:52] ead: Imagine it's "just" a 50% difference, and our AI...) [08:20:35] Just to put even more questions out there: I made proposals for fixing up Z80 as [[Wikifunctions:Type proposals/Byte]] and Z86 as [[Wikifunctions:Type proposals/Unicode codepoint]] [08:24:49] Although I have also remembered that someone (? @vrandecic ) told me that in the future Wikidata would be just one node in a federated system of databases that could be queried all at once. So I don't mind if that's how we get the three orders of magnitude. And if scholarly articles are the first split out of thousands to achieve it, go scholarly articles! (re @Toby: My [08:24:49] loose ana [08:24:49] logy was in no way meant to criticize anyone. I love SPARQL. I love the WDQS. I love Wikidata being big, and I want...) [08:25:56] That's WMDE's plan, yes, a federation of Wikibases (and, if you ask me, other linked open data). [08:33:19] Yes, the capability question is important too, because it weighs on the "programmer ease". It's not just me who has been tripped up by having to remember to use "0n" instead of "0" because we chose (rightly) to get the range available to bigint. In fact I think we still have a few implementations that have this kind of bug. And since volunteers include hobbyists, we [08:33:19] don't want to [08:33:19] scare off too many kids like me who have never used "0n" in their life. (re @vrandecic: And I am not arguing for one side or the other. I think I would be fine with the 3 key solution for Python, and either the 3 key...) [08:35:46] Although I think the current barriers to newcomers writing successful code implementations are things like the unreadability of error messages. [08:37:57] Very true! [08:46:28] Thank you for clarifying. I think there would be no real problem with three-integers if we had re-entrancy. In that case, I think I would be arguing against converting to date objects 🤔 (re @vrandecic: The sooner we have consent, the sooner we'll get the type. Then again we're not in any particular hurry, it's holiday season, I'...) [10:51:11] Al has been typing for about 2 hours... This is gonna be a long one!? [10:53:23] The Gregorian calendar is only “right” until around 3200 CE. Things may change at any time in the future, of course. Or they may not. Even if the calendar is restricted to its non-proleptic period, it is not strictly correct, because the additional day in February was originally achieved by continuing the practice of having February 24th occur twice, so the last day of [10:53:23] Februa [10:53:24] ry was still the 28th (and, by English statute, only one February 24th was counted, so leap years had 365 days in law until 1751/2 when February 29th was recognised) and the first day of the year was moved back to January 1st (from March 25th)). I disregard such complexities when considering the “idealised” representation. 😏 (re @vrandecic: I understand that feeling. One [10:53:24] c [10:53:25] ould argue that beyond the 100000 AD and before 100000 BC the Gregorian proleptic calendar doesn...) [10:56:30] Sorry, I was drifting into irrelevant details. The idealised Gregorian calendar is what it is and the validity of its prolepsis does not concern me. (Except in practice!) (re @Toby: Al has been typing for about 2 hours... This is gonna be a long one!?) [12:03:25] This should be another type. For Rational numbers, we chose not to divide in the converter, and I fear that creating the date will restrict the range for an infinite range type. (re @vrandecic: I understand that feeling. One could argue that beyond the 100000 AD and before 100000 BC the Gregorian proleptic calendar doesn...) [12:06:10] I disagree that creating the date will be faster. You'd have to create and uncreate it, and I actually disagree that there are many uses for the date object, everything it does can necessarily be done manually correctly. (re @Toby: Then I wonder whether we can use our multi-program-language facility to our advantage. We could do python "right", but JS "fast"...) [12:08:18] I'd like to again cite our choice with Rational numbers. Though I agreed with automatic float conversion at the time, it was terrible and scary in hindsight. (re @Toby: Usually I care more about accuracy than speed. But in this case I think we are likely to call these functions quite a lot for Wi...) [12:16:50] Interesting. Packaging recursive compositions might force them to go all the way down by themselves, rather than escaping to a fast JS call. That would have the benefit of ensuring they actually pass the tests on their own merits. (re @vrandecic: Just to give a few ideas why I am not so concerned about compute efficiency of the current system: I am quite confident that [12:16:50] as ...) [12:24:17] I've read the Byte proposal. I wonder if the Arabic digits and Roman characters that make up hex strings are unnecessarily Western-centric. I wonder if option 3 (natural number 0-255) is better, because then the renderers work out of the box. Otherwise every language community needs to also write a renderer for two-hex-digits. (re @vrandecic: Just to put even more [12:24:18] questions out t [12:24:18] here: I made proposals for fixing up Z80 as [[Wikifunctions:Type proposals/Byte]] and Z86 a...) [12:25:25] I very very much disagree (re @Toby: I've read the Byte proposal. I wonder if the Arabic digits and Roman characters that make up hex strings are unnecessarily Weste...) [12:26:27] That's lots of wasted efficiency. [12:26:46] If we wanted to store an image, doing that would be a huge waste. [12:45:10] I think it's fair to consider how we will represent file Types that would traditionally come as lists of bytes. I expect that any internal format that we agree on will take up much more space than the actual binary. Yes, one wrapping and Ntype is less compact than one wrapping a two character string. But we are unlikely to store much onsite. Related questions include: [12:45:10] what do yo [12:45:10] u expect our JPEG type will look like? A list of Bytes? Or a string of some form? How easy will it be to upload a JPEG file and convert it into our internal format so that functions can run on it? (re @Feeglgeef: If we wanted to store an image, doing that would be a huge waste.) [12:47:06] Fair (re @Toby: I think it's fair to consider how we will represent file Types that would traditionally come as lists of bytes. I expect that an...) [12:48:25] @vrandecic can you change the type converters (or disconnect them for changing)? I think there is consensus for it. [12:49:59] Of which type? (re @Feeglgeef: @vrandecic can you change the type converters (or disconnect them for changing)? I think there is consensus for it.) [12:50:15] Gregorian calendar date (re @Toby: Of which type?) [13:01:19] I think we have consensus on the Python 3 key version. Regarding JS I am less clear. Another thing I noticed in Al 's "three (big)int" comment is that none of us has commented on whether there are any issues mixing ints with bigints? (re @Feeglgeef: Gregorian calendar date) [13:03:31] I suppose JS already knows how to deal with this. But I don't have any practical experience of it. (re @Toby: I think we have consensus on the Python 3 key version. Regarding JS I am less clear. Another thing I noticed in Al 's "three (bi...) [13:04:09] {1n, 1, 1} is fine (re @Toby: I think we have consensus on the Python 3 key version. Regarding JS I am less clear. Another thing I noticed in Al 's "three (bi...) [13:06:21] Arithmetic requires one or the other. (re @Toby: I think we have consensus on the Python 3 key version. Regarding JS I am less clear. Another thing I noticed in Al 's "three (bi...) [13:06:53] Yes, but it is unlikely that we are adding the Year to the Months or the Days (re @Al: Arithmetic requires one or the other.) [13:07:26] And if we really do, we can use BigInt() in that specific case [13:17:50] All 4 votes on the type proposal support 3 keys for both. 3 of the votes implicitly preference BigInts, because the 3 key proposal they voted for has BigInts. (re @Toby: I think we have consensus on the Python 3 key version. Regarding JS I am less clear. Another thing I noticed in Al 's "three (bi...) [13:19:53] I imagine many of the functions will need this. For example: Date+ndays; and weekday_of_date; and date-date_in_days. (re @Feeglgeef: Yes, but it is unlikely that we are adding the Year to the Months or the Days) [13:20:48] Those can make the K2s BigInts (re @Toby: I imagine many of the functions will need this. For example: Date+ndays; and weekday_of_date; and date-date_in_days.) [13:23:32] ?? I thought only JS K1 was going to be bigints? (re @Feeglgeef: Those can make the K2s BigInts) [13:24:15] Yes, functions that need to add can make everything BigInts (re @Toby: ?? I thought only JS K1 was going to be bigints?) [13:25:23] We can have a default renderer. I think for something like byte, there is a rarely a local way to render things. But I am just guessing here. (re @Toby: I've read the Byte proposal. I wonder if the Arabic digits and Roman characters that make up hex strings are unnecessarily Weste...) [13:25:49] Side note, do we need a different way to label code converted keys? "K2" could refer to the K2 of the WF type object, or to the JS-converted K2. (re @Toby: ?? I thought only JS K1 was going to be bigints?) [13:26:31] Z0K2 (re @Toby: Side note, do we need a different way to label code converted keys? "K2" could refer to the K2 of the WF type object, or to the ...) [13:27:12] We can also use letters [13:27:19] ZCK1? [13:29:18] I agree many script systems won't have the concept of a hex, but they do usually have a concept of N. (re @vrandecic: We can have a default renderer. I think for something like byte, there is a rarely a local way to render things. But I am just g...) [13:31:31] The good thing is, parsers and renderers can be changed later rather easily. It's just the converters and the structure that are a mess to change. [13:38:37] So in terms of "structure", I think it's clear that it should have just one key. Then for conversion we should just consider which is easiest to convert from internal to code and back. Since the code representation you're suggesting is int types, isn't that most easily translated to and from Ntype? (re @vrandecic: The good thing is, parsers and renderers can be changed [13:38:37] later rath [13:38:37] er easily. It's just the converters and the structure that are...) [13:39:35] Apologies, I don't understand. Could you rephrase? [13:41:49] I'm comparing your Option 1 (strong of two hex digits) to Option 3 (natural number in range [0,255]). [13:42:39] Ah, now I understood [13:45:25] My guess is that option 3 is inherently more multilingual and script-insensitive. But even if you just compare conversion simplicity it is probably also better for that. (re @Toby: I'm comparing your Option 1 (string of two hex digits) to Option 3 (natural number in range [0,255]).) [13:46:04] Both JS and Python have good builtin hex handling. In JS it would be literally the same function (parseInt). I don't think that makes a difference. I am fine with either FF and 255, i just think FF for bytes looks a bit more accustomed, but no strong feelings. I agree with you that a one key solution is the right thing here. [13:53:33] Is that for "code", and if so, can we distinguish the python CK1 from the JS one? (re @Feeglgeef: CK1?) [14:14:09] Yes (re @Toby: Is that for "code", and if so, can we distinguish the python CK1 from the JS one?) [14:14:28] PK1/PYK1 and JK1 or JSK1 [14:20:43] Ah, yes… I’d been looking at the converters… Three BigInts for JavaScript, then? (re @Feeglgeef: All 4 votes on the type proposal support 3 keys for both. 3 of the votes implicitly preference BigInts, because the 3 key propos...) [14:58:12] 3 for one BigInt in the year for JavaScript (re @Al: Ah, yes… I’d been looking at the converters… Three BigInts for JavaScript, then?) [15:08:52] What is that? (re @vrandecic: I have a slightly different view on this: originally, I wasn't for a SPARQL endpoint at all, because I was expecting it to lead ...) [15:09:30] https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_graph_split (re @Feeglgeef: What is that?) [15:13:21] sorry to just paste a link, but basically it's all explained in that page [15:13:37] it's a long story coming, we've been discussing it for two years at least [15:14:11] (I say "we" because I'm helping the Search team since 2021 with the Blazegraph replacement and the WDQS graph split) [16:47:04] Same as Z20342 for month and day and Number or BigInt for year. (re @Feeglgeef: 3 for one BigInt in the year for JavaScript) [17:02:20] Is that your vote? (re @Al: Same as Z20342 for month and day and Number or BigInt for year.) [17:02:43] i.e. a ranked choice vote with both as #1? [17:03:39] Because if so I'd argue we have 4-0-0 consensus for Python 3-key int, int, int and JavaScript BigInt, Number, Number [17:16:05] No, I argue for explicitly limiting the valid range for year. If limited, Number, else BigInt. (re @Feeglgeef: i.e. a ranked choice vote with both as #1?) [17:16:45] Why should we limit the range (re @Al: No, I argue for explicitly limiting the valid range for year. If limited, Number, else BigInt.) [17:16:50] The year type is not limited [17:17:10] It seems counterintuitive to linit the date tyoe [18:38:36] The Gregorian calendar increasingly diverges from “reality” (e.g. Terrestrial Time) as the millennia roll on. There is no way of knowing when adjustments to the formal definition will be made (if at all) but the divergence increases over the millennia. With something as imprecise as a year, there’s no problem, but when you divide the year into days, the divergence becomes [18:38:36] m [18:38:37] aterial after 1500 years or so, which is why Herschel suggested that AD 4000 should not be a leap year. More recent proposals suggest that 3200 should be a leap year and we should then change the 400-year rule to a 500-year one (so that 3500 would be a leap year but 3600 would not). (re @Feeglgeef: Why should we limit the range) [18:41:46] That's kinda like saying that a Rational with numbers of near-infinite length is not valid, because we will change the number system before anything can count to it (re @Al: The Gregorian calendar increasingly diverges from “reality” (e.g. Terrestrial Time) as the millennia roll on. There is no way of...) [18:42:14] Sure, it can't be used, and it may be changed by the time we get to it, but this type is not for the calendar system used at n date, is for our current one [18:44:42] The date January 1, 1000000000000th, while people may not call it that, is still something that is a defined time period. [18:46:07] How many days does that year have? What is its last day? (re @Feeglgeef: The date January 1, 1000000000000th, while people may not call it that at the time of it's date, is still something that is a de...) [18:46:42] 366, and December 31st, according to Inter gravimas (re @Al: How many days does that year have? What is its last day?) [18:47:46] Because the year 1000000000000 is a defined time period, which will share an ending time with December 31st, 1000000000000 [18:49:02] But I consider that to be a statement with no meaning. (re @Feeglgeef: Because the year 1000000000000 is a defined time period, which will share an ending time with December 31st, 1000000000000) [18:49:16] "Deinde, ne in posterum a XII Kalendas Aprilis æquinoctium recedat, statuimus bissextum quarto quoque anno (uti mos est) continuari debere, præterquam in centesimis annis; qui, quamvis bissextiles antea semper fuerint, qualem etiam esse volumus annum MDC, post eum tamen qui deinceps consequentur centesimi non omnes bissextiles sint, sed in quadringentis quibusque [18:49:16] annis primi qu [18:49:16] ique tres centesimi sine bissexto transigantur, quartus vero quisque centesimus bissextilis sit, ita ut annus MDCC, MDCCC, MDCCCC bissextiles non sint. Anno vero MM, more consueto dies bissextus intercaletur, Februario dies XXIX continente, idemque ordo intermittendi intercalandique bissextum diem in quadringentis quibusque annis perpetuo conservetur." [18:50:33] Again, the type proposal says that we are following Inter gravissimas (re @Al: But I consider that to be a statement with no meaning.) [18:54:54] Perhaps we need a "What GrounderUK considers meaningful variation of the Gregorian calendar date" type? (re @Al: But I consider that to be a statement with no meaning.) [18:58:09] I would have more sense than to propose such a type. (re @Feeglgeef: Perhaps we need a "What GrounderUK considers meaningful variation of the Gregorian calendar date" type?) [19:00:35] You literally are? (re @Al: No, I argue for explicitly limiting the valid range for year. If limited, Number, else BigInt.) [19:03:19] No, I’m arguing for not extending a concept so far into the future or the past that it has no discernible meaning or utility. (re @Feeglgeef: You literally are?) [19:03:19] I think we can all benefit from a pause from the discussion [19:46:35] Special:ListObjects by Type https://www.wikifunctions.org/wiki/Special:ListObjectsByType Does not return unique values. Some functions are displayed twice. Is this a new problem or something existing for a longer period of time. [19:47:35] This is almost certainly related to T381003 (re @hogue_456: Special:ListObjects by Type https://www.wikifunctions.org/wiki/Special:ListObjectsByType Does not return unique values. Some fun...) [20:35:44] I tried to check what functions are missing in the Functions catalogue. https://www.wikifunctions.org/wiki/Wikifunctions:Catalogue It is not complete and so some functions are propably already included and still listed at this subpage of my user page. https://www.wikifunctions.org/wiki/User:Hog%C3%BC-456/Non-included_functions_in_Function_catalogue#Exported_Pages [20:56:57] @vrandecic Z20611 should be a completed implementation for Z20597, if you'd like to double-check/fix it. [20:59:44] Anyone know what I'm missing? : https://tools-static.wmflabs.org/bridgebot/56aa3920/file_66883.jpg [21:00:03] Ahh 2020ths decade [21:01:44] Al GrounderUK can you explain again why reentrancy affects the code conversion choices? [21:08:06] When we have re-entrancy, we can develop functions that will map the code representations into and out of date objects with correct handling of offsets. Without re-entrancy, any implementation that requires this will have to copy in the (code) function from some other implementation (I suppose). (re @Toby: Al GrounderUK can you explain again why reentrancy affects the [21:08:06] code conversion choices?) [21:11:09] But will they be able to return objects which are not supported wikifunctions types? (E.g date objects) (re @Al: When we have re-entrancy, we can develop functions that will map the code representations into and out of date objects with corr...) [21:20:19] Those are both good questions! I’m assuming that we wouldn’t be using the converters for “same-language” re-entrancy, but, still… I can only further assume that a native object like Date would be a Z1 or similar in Wikifunctions …maybe 🤷‍♂️ (re @Toby: But will they be able to return objects which are not supported wikifunctions types? (E.g date objects). What message> [21:20:19] will their WF func...) [21:29:57] My assumption was that the first answer will be: no. (re @Al: Those are both good questions! I’m assuming that we wouldn’t be using the converters for “same-language” re-entrancy, but, still...) [21:31:02] Perhaps we should have a category "Enwiki text generation" or something similar (re @Feeglgeef: @vrandecic Z20611 should be a completed implementation for Z20597, if you'd like to double-check/fix it.) [21:32:57] To make it a defined time period the pope would also need to fix the period of the Earth's orbit for long after the earth remains in orbit. (re @Feeglgeef: Because the year 1000000000000 is a defined time period, which will share an ending time with December 31st, 1000000000000) [21:34:38] Well, functions can already return undefined objects, so… 🤷‍♂️ (re @Toby: My assumption was that the first answer will be: no.) [21:34:52] "Dum itaque nos quoque, credita nobis, licet indignis, a Deo dispensatione freti, in hac cogitatione curaque versaremur, allatus est nobis liber a dilecto filio Antonio Lilio, artium et medicinæ doctore, quem quondam Aloysius eius germanus frater conscripserat, in quo per novum quemdam epactarum cyclum ab eo excogitatum, et ad certam ipsius aurei numeri normam [21:34:52] directum, atque ad [21:34:52] quamcumque anni solaris magnitudinem accommodatum, omnia quæ in calendario collapsa sunt, constanti ratione et sæculis omnibus duratura, sic restitui posse ostendit ut calendarium ipsum nulli umquam mutationi in posterum expositum esse videatur. Novam hanc restituendi calendarii rationem, exiguo volumine comprehensam, ad christianos principes celebrioresque [21:34:52] universitates pauco [21:34:54] s ante annos misimus, ut res quæ omnium communis est, communi etiam omnium consilio perficeretur; illi cum, quod maxime optabamus, concordes respondissent, eorum nos omnium consensione adducti, viros ad calendarii emendationem adhibuimus in alma Urbe harum rerum peritissimos, quos longe ante ex primariis christiani orbis nationibus delegeramus. Ii cum multum [21:34:54] temporis et diligent [21:34:55] iæ ad eam lucubrationem adhibuissent, et cyclos tam veterum quam recentiorum undique conquisitos ac diligentissime perpensos inter se contulissent, suo et doctorum hominum, qui de ea re scripserunt, iudicio, hunc, præ ceteris, elegerunt epactarum cyclum, cui nonnulla etiam adiecerunt, quæ ex accurata circumspectione visa sunt ad calendarii perfectionem maxime [21:34:55] pertinere." (re @ [21:34:57] Toby: To make it a defined time period the pope would also need to fix the period of the Earth's orbit for long after the earth remain...) [21:35:48] It already implicitly does [21:36:16] I don't read Latin, but I can't see anything with more than twelve significant figures in there. [21:39:17] "et ad certam ipsius aurei numeri normam directum, atque ad quamcumque anni solaris magnitudinem accommodatum, omnia quæ in calendario collapsa sunt, constanti ratione et sæculis omnibus duratura, " roughly translates to "And directed to the certain standard of the Golden Number itself. and adapted to whatever the magnitude of the solar year, all that has collapsed [21:39:17] in this cale [21:39:18] ndar, with a constant ration and lasting all ages" [21:39:36] So the papal bull defines a Solar Year as however long this calendar says it is [21:41:38] (i.e. 365.2425 days) [21:43:43] Actually, it's whatever this *guy* says it is [21:44:28] The guy being "our beloved son Antonius Lilius from Germany" [21:49:43] But is a "day" a certain invariant number of seconds (if so, how many to 12 sig figs?), or something to do with counting sunrises (if so, that date will never happen). [21:50:39] A day is, by the definition of seconds, 86400 of them (re @Toby: But is a "day" a certain invariant number of seconds (if so, how many to 12 sig figs?), or something to do with counting sunrise...) [21:53:46] If you prefer the Cesium standard (so aliens can figure it out), it's 794,243,384,932,000 [22:00:53] I've lived through many days that were 86401 seconds long. (re @Feeglgeef: A day is, by the definition of seconds, 86400 of them) [22:01:20] By the pope? (re @Toby: I've lived through many days that were 86401 seconds long.) [22:05:42] That's my point. I think he was silent on how long a year is exactly (in SI units). Therefore I contend that 1000000000000 is not a defined time period. (re @Feeglgeef: Did the pope decide to make the day longer?) [22:11:04] And I don't just mean it could be one second different in length. I mean different valid interpretations of the bull could have it starting many Tuesdays apart. [22:11:07] The papal bull implies that the length of a year is equal to the amount of time it would take for 290,091,439,521,026,010 photon absorptions by transitions between the two hyperfine ground states of caesium-133 atoms (re @Toby: That's my point. I think he was silent on how long a year is exactly (in SI units). Therefore I contend that 1000000000000 is no...) [22:12:41] That will be true in the year 1000000000000 [22:46:58] Interesting extrapolation, I can't see that many significant figures myself. But I'll agree that on your interpretation, 1000000000000 is now a defined time period (relativistic frame of reference excepted). However, this interpretation causes us an immediate problem. For the first 27 seconds after midnight tonight, your clock will not be showing the "correct" Gregorian [22:46:58] date. Doe [22:46:58] s that not trouble you/wikifunctions? (re @Feeglgeef: The papal bull implies that the length of a year is equal to the duration of 290,091,439,521,026,010 periods of the radiation co...) [22:58:38] My clock will be telling me the date that is correct in *solar time* in *my time zone*. This is not a Solar time type. (re @Toby: Interesting extrapolation. I can't see that many significant figures myself. But I'll agree that on your interpretation, 1000000...) [22:59:36] Actually, the Timezone+Day+Time proposal could be solar time? I'll concede that, I don [23:00:28] As well as Date+Timezone, if we do create that [23:17:59] I've created a category, [[Category:Enwiki Textgen]] for functions like Z20656 and Z20597 [23:37:16] Can others reproduce this glitch in Z14280? I started writing it up as a test, but it seems to work there (in draft at least). : https://tools-static.wmflabs.org/bridgebot/d95a2004/file_66888.jpg