[00:09:57] Hmmm... that may be the way the function works, but it makes no sense for actual calendars, so basically limits the range of usefulness of the function. I don't think it's an issue with the Type. (re @Feeglgeef: They don't have a year attached, so could be thought of as existing all in the same year, thus if it were a leap year once it wo...) [00:21:09] The function is using the type that's inherently less useful, obviously the range of usefulness is smaller (re @Toby: Hmmm... that may be the way the function works, but it makes no sense for actual calendars, so basically limits the range of use...) [00:21:42] Sure it makes no sense for actual calendars, but if we wanted a type that worked well with actual calendars, we would use the date type [00:21:59] We will. (re @Feeglgeef: Sure it makes no sense for actual calendars, but if we wanted a type that worked well with actual calendars, we would use the da...) [00:23:22] Yeah, we should, so I think we should treat the Roman Day type as existing in one year, to give it the little purpose we can still suck out of it (re @Toby: We will.) [00:24:23] So, adding -1 days is the same date and adding 355. (See the equality function) [00:25:06] If you're looking for good functions to write for this type, here are some suggestions: *later in year, *earlier in year, *number of days between dates (with leap flag), *?astrological sign corresponding to date ... [00:26:08] ... *month of date, *day of date [00:26:10] Idk how tf I got 355 it's 364 (re @Feeglgeef: So, adding -1 days is the same date as adding 355. (See the equality function)) [00:27:03] ...*increment date by 1 day, *increment date by 1 month [00:28:00] If the year is unknown, each crossing of the February/March boundary affects the uncertainty of the result but I think that can be quantified as +/- 2 days (assuming no calendar abnormalities other than a leap day). In some cases, this uncertainty would be known to be 0, but in general it would (0 or 1) or (1 or 2), positive or negative. (I think.) (re @Toby: Hmmm... that [00:28:00] may be [00:28:00] the way the function works, but it makes no sense for actual calendars, so basically limits the range of use...) [00:29:07] Isn't it only 1? Why 2? (re @Al: If the year is unknown, each crossing of the February/March boundary affects the uncertainty of the result but I think that can ...) [00:29:44] *increment date by 1 week (with leap flag) [00:30:59] ...*first date of month *last date of month (leap flag) [00:32:17] Because a five-year period crossing a century may have 0, 1 or 2 leap days. (re @Feeglgeef: Isn't it only 1? Why 2?) [00:34:13] ...*is new year's day *is Christmas day, *is Christmas eve *is Boxing day, etc [00:35:25] I don't think we need to curry the equality function (re @Toby: ...*is new year's day *is Christmas day, *is Christmas eve *is Boxing day, *is solstice, etc) [00:35:40] ...*days are shorter than nights (hemisphere flag) [00:35:55] Like I literally can't think of a use for these (re @Feeglgeef: I don't think we need to curry the equality function) [00:36:39] here's one, a composition for *is fixed date religious holiday (re @Feeglgeef: Like I literally can't think of a use for these) [00:38:01] I would use a function that has a list for this one, instead of all those function calls (re @Toby: You don't have to write them. But to expand imagination, here's one, a composition for *is fixed date religious holiday) [00:39:32] That's up to you, but it doesn't mean we shouldn't have them. I agree they're not the most important, but they're valid concrete uses for this type. (re @Feeglgeef: I would use a function that has a list for this one, instead of all those function calls) [00:41:05] (whereas your "really useful" Z20367 turns out to have some serious definition/scope limitations within this type) [00:42:07] I'd imagine it would be one of the most used for the type (other than trivial things like the equality function) (re @Toby: (whereas your "really useful" Z20367 turns out to have some serious definition/scope limitations within this type)) [00:42:15] I'm not saying really useful in general [00:42:22] I'm saying really useful for this type [00:44:06] This type as a whole I see is only really used because of the complete type with the year. [00:44:27] I don't see many applications of the type itself [00:44:59] But once we do get the type, I think it will be well used (like the Rational Number type) [00:45:06] That will certainly be it's major role. But I think all of the functions I've listed can be made rigorous. (re @Feeglgeef: This type as a whole I see is only really used because of the complete type with the year.) [00:46:16] Yeah (re @Toby: That will certainly be it's major role. But I think all of the functions I've listed can be made rigorous with this type alone.) [00:48:51] @vrandecic I'd also like to for "moment in time" to be created, because it would combine all the types recently created. I'll create a type proposal with the specifics that I'd like. [00:48:53] ... dates are in same calendar month [00:49:25] Solstices vary a bit by year as do equinoxes. In the UK, Boxing Day cannot fall on a Sunday, so… (re @Toby: That will certainly be it's major role. But I think all of the functions I've listed can be made rigorous with this type alone.) [00:49:26] make sure this lines up with point-in-time data coming from wikidata (re @Feeglgeef: @vrandecic I'd also like to for "moment in time" to be created, because it would combine all the types recently created. I'll cr...) [00:50:14] I'm not sure what format that is using, but I was thinking Calendar Date + Fraction representing fraction of completed day in UTC (re @Toby: make sure this lines up with point-in-time data coming from wikidata) [00:50:45] This would allow for infinite expansion in a clean way [00:50:53] Yes, I agree solstices are dicey. I didn't know about your Sunday rule. (re @Al: Solstices vary a bit by year as do equinoxes. In the UK, Boxing Day cannot fall on a Sunday, so…) [00:51:48] And if it's not, (e.g. they use ms) it would be really easy to convert (re @Feeglgeef: I'm not sure what format that is using, but I was thinking Calendar Date + Fraction representing fraction of completed day in UT...) [00:51:54] Find out before you write the proposal. This is 100% important. (re @Feeglgeef: I'm not sure what format that is using, but I was thinking Calendar Date + Fraction representing fraction of completed day in UT...) [00:52:19] Would have thought you knew (re @Toby: Find out before you write the proposal. This is 100% important.) [00:54:30] I have a rough idea. https://www.w3schools.com/xml/schema_dtypes_date.asp (re @Feeglgeef: Would have thought you knew) [00:54:42] From what I've quickly read, they do allow time zones, but other than that they use ISO 8601, which would be really easy to convert to my proposal (re @Toby: Find out before you write the proposal. This is 100% important.) [00:55:53] We do like to keep things interesting 😏 (re @Toby: Yes, I agree solstices are dicey. I didn't know about your Sunday rule.) [00:56:24] I know someone whose wedding date is incorrect in en-wiki because a US editor assumed there was no timezone difference when they saw the instagram post. (re @Feeglgeef: From what I've quickly read, they do allow time zones, but other than that they use ISO 8601, which would be really easy to conv...) [00:57:13] Maybe we need a Timezone type first? [00:57:17] The converter would handle time zone changes, of course (re @Toby: I know someone whose wedding date is incorrect in en-wiki because a US editor assumed there was no timezone difference when they...) [00:57:53] If they didn't think there was a time zone difference, they wouldn't have thought to label the time zone! (re @Toby: I know someone whose wedding date is incorrect in en-wiki because a US editor assumed there was no timezone difference to Austra...) [00:58:35] Wikimedia projects use UTC as standard, so we ought to [00:59:19] If it is eventually correct in Wikidata, then good templates will propagate it correctly to Wikipedias using our excellent Wikifunctions Date type functinos. (re @Feeglgeef: If they didn't think there was a time zone difference, they wouldn't have thought to label the time zone!) [01:00:16] The Wikipedias will want to use UTC. (re @Toby: If it is eventually correct in Wikidata, then good templates will propagate it correctly to Wikipedias using our excellent Wikif...) [01:00:19] That's okay as a default, but we can do better than that at representing global diversity. (re @Feeglgeef: Wikimedia projects use UTC as standard, so we ought to) [01:00:36] This should be it's own type, to come later (re @Toby: That's okay as a default, but we can do better than that at representing global diversity.) [01:00:46] With a Timezone type, of course [01:01:55] We should have a standard for the bare case, a real moment in time first (like we did for rational numbers) [01:02:01] No, not for a wedding date, or for a date of birth, etc. Some of my children would have a different date of birth if you insisted on expressing it in UTC, but that would be extremely confusing for everyone. (re @Feeglgeef: The Wikipedias will want to use UTC.) [01:02:11] Then, we go for matching something else [01:03:08] JavaScript computations are really confusing with our Rational Number type, but we push through with the hope of a future float type. I propose we do the same thing. (re @Toby: No, not for a wedding date, or for a date of birth, etc. Some of my children would have a different date of birth if you insist...) [01:04:02] I don't think they are analogous. When we set up a point in time, we have the opportunity to choose to include a timezone. (re @Feeglgeef: JavaScript computations are really confusing with our Rational Number type, but we push through with the hope of a future float ...) [01:04:43] A point in time is the same point in time in a different time zone, but would be different objects. We explicitly chose not to do this for rationals (re @Toby: I don't think they are analogous. When we set up a point in time type, we have the opportunity to choose to include a timezone.) [01:05:18] Of course, we will need to represent all time zones, but I think that's a job of a near future type. [01:09:55] In any case, one of the most important things to me is that we can correctly interpret and represent point in time data from Wikidata such as an example given on https://www.wikidata.org/wiki/Help:Dates "{"time":"-0458-00-00T00:00:00Z","timezone":0,"before":0,"after":0,"precision":9,"calendarmodel":"http://www.wikidata.org/entity/Q1985786"}" So bear this in mind when [01:09:55] writing any [01:09:56] proposal (otherwise I will definitely raise this same issue in the discussion). [01:11:35] any of "timezone", "before", "after", "precision", "calendarmodel" could be important keys [01:32:48] @vrandecic can Natural numbers get a validator? I think they need one, especially given their use in many types. [01:33:13] In case this goes ahead, I've disconnected Z20253 because the outcome depends on the value of Z20250. To me it is not clear if this persistent object is intendent to stay constant (2025) or to be updated with time. If the former, the test becomes a duplicate of Z20254 and could be deleted. If the latter, the test result will change with time, so should not stay [01:33:13] connected. (re @Al [01:33:14] : Maybe add suggestions to [[Wikifunctions:Function_of_the_Week#Suggest_your_own_Function_of_the_Week]]? Z10996 is already a sugge...) [01:34:59] Z20250 is planned to be updated, yes. I plan to manually fix all the tests with wf-usage. (re @Toby: In case this goes ahead, I've disconnected Z20253 because the outcome depends on the value of Z20250. To me it is not clear if t...) [01:35:55] Nevermind, it will stay the same, so it is a duplicate (though, technically newer) [01:36:39] IMO plans cannot be relied upon.... ^^^haha... the plan changed as I was writing this sentence! (re @Feeglgeef: Z20250 is planned to be updated, yes. I plan to manually fix all the tests with wf-usage.) [01:38:32] I don't really care which one gets deleted, but the older one usually stays when there are duplicates [01:38:52] It certainly has a good ZID to stay constant. So maybe change the title/description of the persistent object to make this clear. (re @wikilinksbot: Z20250 – Next year) [01:44:26] Did that (re @Toby: It certainly has a good ZID to stay constant. So maybe change the title/description of the persistent object (e.g. "2025 AD") to...) [01:45:01] It'll be nice and easy to search for should a reference be ideal (re @Toby: It certainly has a good ZID to stay constant. So maybe change the title/description of the persistent object (e.g. "2025 AD") to...) [01:45:18] And it just has a cool ZID [01:46:32] I don't mind if you add a temporary "next year" alias as well to aid discoverability. (re @Feeglgeef: It'll be nice and easy to search for should a reference be ideal) [01:53:53] I've also disconnected Z20308 for now. You may want to work on it now in case it is featured. [01:57:49] Please delete Z20308, actually (re @Toby: I've also disconnected Z20308 for now. You may want to work on it now in case it is featured. (also give it a label)) [02:17:02] Done. Since it was already disconnected, it didn't trigger T379873, so I guess this is the correct procedure without manual editing: disconnect then delete. (re @Feeglgeef: Please delete Z20308, actually) [03:15:58] I'm a little confused. d:Help:Dates says that precision above day is not supported on Wikidata. (re @Toby: In any case, one of the most important things to me is that we can correctly interpret and represent point in time data from Wik...) [03:19:57] Done, [[WF:TP/MT]] (re @Feeglgeef: @vrandecic I'd also like to for "moment in time" to be created, because it would combine all the types recently created. I'll cr...) [03:21:36] Yes, but since there are requests to improve that, it sounds like we should try to support in advance. (re @Feeglgeef: I'm a little confused. d:Help:Dates says that precision above day is not supported on Wikidata.) [03:22:12] Then would you like me to put a Wikidata integration section using what the page says might come in the future? (re @Toby: Yes, but since there are requests to improve that, it sounds like we should try to support in advance.) [03:25:37] We should certainly support the precisions they already have, and if we do that it would be a trivial difference for us to also support more. (re @Feeglgeef: Then would you like me to put a Wikidata integration section using what the page says might come in the future?) [03:26:26] The precisions they already have would have to be handled by the date type? (re @Toby: We should certainly support the precisions they already have, and if we do that it would be a trivial difference for us to also ...) [03:30:49] Yes? Maybe we need "exact" and "inexact"(with precision expressed) versions of both of these types??? Or a key to flag which one it is? This could be tricky, but is worth getting right so we can interface with statements from Wikidata. (re @Feeglgeef: The precisions they already have would have to be handled by the date type?) [03:32:51] I mean I suppose we could have ZNNNK1 accept A year, a month and a year, or a date (re @Toby: Yes? Maybe we need "exact" and "inexact"(with precision expressed) versions of both of these types??? Or a key to flag which on...) [03:58:45] I'm coming around to your analogy now that I'm thinking harder about the precision issue. (re @Feeglgeef: A point in time is the same point in time in a different time zone, but would be different objects. We explicitly chose not to d...) [03:59:50] I'm not sure what you mean here. I think keys need a predefined type. (re @Feeglgeef: I mean I suppose we could have ZNNNK1 accept A year, a month and a year, or a date) [04:00:54] Which can be a Z1 (re @Toby: I'm not sure what you mean here. I think keys need a predefined type.) [04:01:23] True, but that would be way too vague IMO. (re @Feeglgeef: Which can be a Z1) [04:04:03] The validator could do the actual restricting. (re @Toby: True, but that would be way too vague IMO.) [04:04:32] I think we will end up needing some types that can contain keys of many different types [04:05:56] Al has suggested this need too I think. I'm not experienced enough to know. (re @Feeglgeef: I think we will end up needing some types that can contain keys of many different types) [04:06:56] Not experienced with what? Haven't you created like 1/5th of the objects on WF? (re @Toby: Al has suggested this need too I think. I'm not experienced enough to know.) [04:08:57] Haha maybe. I mean I don't know enough programming theory to weigh the costs and benefits of subtypes/supertypes. (re @Feeglgeef: Not experienced with what? Haven't you created like 1/5th of the objects on WF?) [04:09:48] https://xtools.wmcloud.org/pages/www.wikifunctions.org/99of9 (re @Toby: Haha maybe. I mean I don't know enough programming theory to weigh the costs and benefits of subtypes/supertypes.) [04:10:32] Ahh okay. I think it would be somewhere from useful to basically necessary (re @Toby: Haha maybe. I mean I don't know enough programming theory to weigh the costs and benefits of subtypes/supertypes.) [04:12:06] Yikes. I hope some of them will be useful!! (re @Feeglgeef: https://xtools.wmcloud.org/pages/www.wikifunctions.org/99of9) [04:16:09] I guess that one perspective from experience is that we have to work very hard to make functions that operate well on lists of arbitrary objects. Whereas functions that work only on lists of a specific type of objects are much easier. (re @Feeglgeef: Ahh okay. I think it would be somewhere from useful to basically necessary) [04:20:20] Yeah that's fair. I would support some kind of normalize function for each type we create that would normalize to a type of a function's choice (re @Toby: I guess that one perspective from experience is that we have to work very hard to make functions that operate well on lists of a...) [04:26:38] So, normalize_natural_number(3, integer) = (Z)+3, and normalize_natural_number(3, rational) = +(3)/(1) ? I suppose this is doable. (re @Feeglgeef: Yeah that's fair. I would support some kind of normalize function for each type we create that would normalize to a type of a fu...) [04:27:45] I was more thinking normalize_quantity(natural number (3), integer) = +3 [04:27:51] But yeah [04:28:33] This way if I have a list of quantities with unknown types I can still look through and normalize to what I want to use [04:31:48] I can see it working if it only goes up the hierarchy, but it would be challenging to know what to do when asked normalize_quantity(integer(-3), natural number). Is this an error? (re @Feeglgeef: I was more thinking normalize_quantity(natural number (3), integer) = +3) [04:32:21] That's pretty clearly 3 (re @Toby: I can see it working if it only goes up the hierarchy, but it would be challenging to know what to do when asked normalize_quant...) [04:33:38] If you don't want to deal with that, don't use natural number to normalize to 🤷‍♂ [04:44:00] It sounds like you favour Z17144 over (new) Z20391. But I guess we'd have to make harder and harder choices as you ask about rounding rational(11/2) to an integer or normalising(1+2i) to a rational number, etc. Nevertheless, I think one that only goes up the hierarchy would be well defined. (re @Feeglgeef: That's pretty clearly 3) [04:58:10] I don't know why you think that. wikimedia projects use local time for almost everything. dates of birth are expected to be the date in the place of birth, date for events are given as the date in the location they take place, etc. utc only really makes sense for things that don't have any obvious local time, and there are exceptions to that too, e.g. wmf often uses [04:58:10] anywhere on e [04:58:10] arth for deadlines (re @Feeglgeef: Wikimedia projects use UTC as standard, so we ought to) [05:08:36] and it should take into account the fact that precisions below day are not supported, the before/after/timezone fields are not supported, and the Z does not actually mean utc (re @Toby: In any case, one of the most important things to me is that we can correctly interpret and represent point in time data from Wik...) [05:34:37] I personally wouldn't worry too much about what wikidata might support in the future though. a lot of what people want support for doesn't work with the current datatype (e.g. other calendars, approximate dates, other subsets of years like seasons/weeks/quarters... there's a request for edtf support at https://phabricator.wikimedia.org/T207705 as well), and we've been [05:34:37] waiting ove [05:34:38] r a decade already just for the existing values to be displayed correctly, let alone any new stuff (re @Toby: Yes, but since there are requests to improve that, it sounds like we should try to support in advance.) [05:39:51] a 2018 request still in "needs triage (re @Nikki: I personally wouldn't worry too much about what wikidata might support in the future though. a lot of what people want support f...) [06:37:11] Good question, I don't know. I was thinking to slip in the date today or tomorrow, and possibly next week to skip because the team is traveling to meet each other in person (re @Feeglgeef: Is the type/week thing expected to continue or is it only for these few cases?) [18:32:42] It doesn’t ring a specific bell, I’m afraid. (re @Toby: Al has suggested this need too I think. I'm not experienced enough to know.) [18:32:43] I think this is what I had in mind. Maybe it's a similar kind of supertyping? (re @Al: Not “almost”… “absolutely”) [18:32:45] Ah, I see what you mean. Yes, it makes sense to me to view a human “point” in time as some “quantity” of time that occurs some “quantity” of time after some “point”/“quantity” of time. We define a time origin (essentially arbitrary, but call it t0) and a point in time is some “number” of seconds (for example, and SI compatibility) after t0, where “number [18:32:46] ” is (I think, for all practical purposes) a rational number 🤷‍♂️ (re @Toby: I think this is what I had in mind. Maybe it's a similar kind of supertyping?) [18:32:48] I'm not necessarily holding you to that specific version of a generic supertype (numeric which accepts any of N, Z, Q, etc). But here Feeglgeef is proposing a generic supertype which accepts any of date, year, month year, etc. All I'm saying is that you both seem to want types or keys which can contain multiple types. (re @Al: Ah, I see what you mean. Yes, it makes [18:32:48] sense to me to [18:32:49] view a human “point” in time as some “quantity” of time that occurs some “...) [18:32:51] Okay, but “any of N, Z, Q” is just Q, in my book. But when it comes to segmenting time, we’re essentially overlaying conventions on top of conventions. I don’t think a “time of day” is the same type as a “moment in time”. (re @Toby: I'm not necessarily holding you to that specific version of a generic supertype (quantity which accepts any of N, Z, Q, etc). Bu...) [18:33:30] Feeglgeef this appears to have the wrong input type for the year: Z20371 [18:33:52] I have the data locally and monitoring recent changes, so it should say updated [18:33:56] Okay. Comment on T271963, do you mean? [18:33:58] yes (re @Al: Okay. Comment on T271963, do you mean?) [21:15:01] T271963#10359585 (re @Sannita: yes) [21:16:23] thanks (re @Al: T271963#10359585)