[01:41:03] As you imply below, it can work for either, depending on one's definition of "day". My understanding of this function would be something like: what is the calendar label [y,m,d] given to the next period of time civilly labelled a "day" (as long as it corresponds to the period of roughly one revolution of the earth, and is occasionally recalibrated to ensure it doesn't [01:41:04] drift with [01:41:04] respect to to the daylight hours for fixed places on earth). Although these "days" are not of a fixed length, the calendar sequence is still likely to be fixed for the next few thousand years. Gregory's labelling could theoretically continue much longer than that, but is known to become more and more problematic with respect to fixing the seasons in the calendar year, [01:41:04] which Grego [01:41:06] ry would hate. Beyond some point much smaller than 250,000 years, it is certain to have been superseded or changed. (re @Feeglgeef: E.g. Next day involves dates as a unit of time instead of a measure of the solar cycle) [01:43:13] I'd argue that said function is completely independent of the context of the sun (re @Toby: As you imply below, it can work for either, depending on one's definition of "day". My understanding of this function would be s...) [01:43:16] I'm probably fine with that. By "forced limits" do you mean you don't want a validator to prevent large-year objects being passed to functions? If so, could we at least have the JS converter to code return an error if the key comes in outside the JS range? (re @Feeglgeef: How about we come to an interim solution, as I think that consensus may be hard to achieve? I think [01:43:16] that, for [01:43:16] now, we give the d...) [01:45:06] You can try to construct something like that (and you did). It's just not my definition of "day", and soon causes trouble reconciling it with every Earthling's functional use of the word. (re @Feeglgeef: I'd argue that said function is completely independent of the context of the sun) [01:45:43] When I ask "How many days till Christmas?" I'm asking how much *time* until Christmas, not How many *times will the sun rise*. My internal system of time is based off of the one with the sun, but when most people think of days, I'd imagine they think of it as a unit of time. [01:45:51] "This task is due in 5 days" [01:46:06] "The week is 7 days long" [01:47:10] If the manager expected the task be done in 5 days, but the rotation of the earth slows down by half which magically does not have an effect on regular day to day stuff, he's going to be mad if you finish it in 10 [01:47:52] If you were talking about seconds, I would agree with you. But I think humanity has generally agreed that a "day" may sometimes contain a different number of seconds. [01:48:50] Sure, slightly, but I don't see that as a reason to disconnect from earth. Most people think of a Day as a unit of time. (re @Toby: If you were talking about seconds, I would agree with you. But I think humanity has generally agreed that a "day" may sometimes ...) [01:49:22] Anyway, we've been over this. I don't think you'll convince me that it is helpful to define a "day" in an SI-like way, because we already have an excellent SI definition of time. [01:49:49] Sure (re @Toby: I'm probably fine with that. By "forced limits" do you mean you don't want a validator to prevent large-year objects being passe...) [01:50:51] I'm pretty sure this is more of an opinion than objective fact discussion as well (re @Toby: Anyway, we've been over this. I don't think you'll convince me that it is helpful to define a "day" in an SI-like way, because w...) [01:51:59] That would help function writers to avoid error-handling themselves. (re @Feeglgeef: Sure) [01:53:51] Additionally, I think that in this discussion is that what we want is two different types other than t [01:55:21] What you more want is a way to represent days for people on earth, where a Timezoned Day is more appropriate. What I more want is a way to represent Units of time, compared to an anchor time, where something like a Unix time would be more appropriate. [01:56:23] So I think that the interim solution will give everyone most of what they want, and two new types could be exactly what they want. [01:58:27] I'll write a proposal for a Time zone type. It would be an identity type, so it shouldn't be controversial. [02:01:02] Actually, I'd rather a timezoned "point in time" rather than a timezoned day. And want it to be as interoperable with Wikidata's point in time as possible. But yes, this will need a Time zone type. (I don't think we need a separate day one apart from manipulating calendar labels as we've discussed above.) (re @Feeglgeef: What you more want is a way to represent days for [02:01:02] people on [02:01:03] earth, where a Timezoned Day is more appropriate. What I more want i...) [02:10:08] Should we use tz database for aliases? This would make searching in general easier and would allow more convenience for users who do not know time zones but do know cities. [02:10:09] E.g. UTC+0 would be called "UTC+0/GMT" [02:10:10] And have the aliases "Dublin", "Lisbon", "London", "Troll" etc.? [02:27:43] WF:TP/TZ (re @Feeglgeef: I'll write a proposal for a Time zone type. It would be an identity type, so it shouldn't be controversial.) [02:28:27] [[WF:TP/TZ]] [03:50:09] On a completely unrelated note, for abstract content, we should have a separate ID system for keys. This would make it easier to write, as you would have to remember less, and would give functions a better idea of what to expect. I would suggest this system be something like "AK1" for "Subject" and "AC1" for "Article", where "AK" stands for Abstract Key, and "AC" [03:50:09] for Abstract Con [03:50:10] structor. Specific details about the keys would go inside of them, which I think makes more sense. [03:50:12] Here's some I think we could have: [03:50:13] AK1: subject [03:50:15] AK2: object [03:50:16] AK3: criteria (by) [03:50:18] AK4: constraint(s) [03:50:19] AK5: reason(s) [03:50:21] AK6: quality [03:50:22] AK7: quantity [03:50:24] AC1 article [03:50:25] AC2: comparison [03:50:27] AC3: superlative [03:50:28] AC4: definition [03:50:30] AC5: ranking [03:50:31] AC6: composition [03:50:33] AC7: description [03:50:34] AC8: action [03:50:36] AC9: name [03:50:37] I've managed to abstractify 1 enwiki article with only these so far, https://en.wikipedia.org/wiki/Battle_of_Aleppo_(2024) [05:42:24] Just to summarize/rewrite this and messages above/below of relevant topic for Al GrounderUK and @vrandecic, Toby and I have agreed that (at least, that's what I'd interpret the 👍 to mean) we are trying to shape the Gregorian date type into something similar to what would be better suited to other types, and the discussion has mainly gone from one of objective fact [05:42:24] to one of pe [05:42:25] rsonal opinion. I've come up with a middle-ground proposal to use until we get the types we really want, which would make the least people upset. We would make the type naive in whether the type is for literal time units or for the Earth's motion in relation to the Sun. The type would not *enforce* limits with the Validator, but the only range of expected support [05:42:25] is that of JavaS [05:42:27] cript, or something near that of JavaScript. Later, two more types, Moment in Time with Timezone (or Date with Timezone) and Period of Time would be created. (re @Feeglgeef: How about we come to an interim solution, as I think that consensus may be hard to achieve? I think that, for now, we give the d...) [10:10:25] Hi y'all, [10:10:25] As I mentionned before, I created a subpage of the catalog for colours: https://www.wikifunctions.org/wiki/Wikifunctions:Catalogue/Colour_functions [10:10:27] Feel free to comment or directly improve this page [10:10:57] (I didn't add it to the main page yet, I need to draw the icon and I want to let some time for people to comment) [11:50:28] How do you draw them (re @Nicolas: (I didn't add it to the main page yet, I need to draw the icon and I want to let some time for people to comment)) [11:54:44] with Inkscape (re @cvictorovich: How do you draw them) [12:47:12] Thanks. I have updated my comments on the proposal (on-wiki). (re @Feeglgeef: Just to summarize/rewrite this and messages above/below of relevant topic for Al GrounderUK and @vrandecic, Toby and I have agre...) [13:41:24] @vrandecic thoughts? (re @Feeglgeef: On a completely unrelated note, for abstract content, we should have a separate ID system for keys. This would make it easier to...) [14:46:03] (please consider that it's Sunday and that in two days the Wikifunctions/Abstract Wikipedia team will have its in-person meeting, so Denny, I and the rest of the team might be slow to answer for all of next week) [14:46:28] 👍 (re @Sannita: (please consider that it's Sunday and that in two days the Wikifunctions/Abstract Wikipedia team will have its in-person meeting...) [23:47:48] I'd actually like to retract the expectation range thing, we should expect infinite, as with all the types we currently have. Python and JS implementations can easily use the modulo if they need to use the date object (which, they shouldn't need to) (re @Feeglgeef: How about we come to an interim solution, as I think that consensus may be hard to achieve? I think [23:47:48] that, for now, we give the d...)