Wikifunctions:Type proposals/Julian calendar date
Summary
A Julian calendar date identifies a specific day using the Julian calendar system introduced in 45BC, using the current numbering of years.
The Type is proleptic, i.e. it is also calculated backwards before its introduction. There is no year 0. Another type can be introduced that has a year 0. The Type is naïve with regards to UTC, i.e. it ignores it as it only resolves to the level of days. When we introduce Functions and Types with a higher resolution, we need to resolve possible discrepancies.
Uses
- Why should this exist?
In order to be able to reference Julian dates and have functions that work with Julian dates.
- What kinds of functions would be created using this?
- How old was a person when they died?
- How many days have passed between two days
- What day of the week was a certain day
- What is this date in another calendar? (requires the other calendar)
- What standard concepts, if any, does this align with?
The Julian calendar date was historically widely used. It was introduced by Julius Cesar.
This is not the same as the time datatype in Wikidata, but it can be used in using it.
Structure
A Julian calendar date has the same structure as the Gregorian calendar date. Thus it has two keys:
- K1 of Type Gregorian year
- K2 of Type Roman day of the year
Example values
Value for October 27, 1014:
{
"type": "Gregorian calendar date",
"year": {
"type": "Gregorian year",
"era": "CE",
"year": {
"type": "Natural number",
"value": "1014"
}
},
"day of the year": {
"type": "Day of the Roman year",
"month": "October",
"day": {
"type": "Natural number",
"value": "27"
}
}
}
|
{
"Z1K1": "Znnn",
"ZnnnK1": {
"Z1K1": "Zppp",
"ZpppK1": "Zqqq",
"ZpppK2": {
"Z1K1": "Z13518",
"Z13518K1": "1014"
}
},
"ZnnnK2": {
"Z1K1": "Zmmm",
"ZmmmK1": "Z16110",
"ZmmmK2": {
"Z1K1": "Z13518",
"Z13518K1": "27"
}
}
}
|
Validator
The validator ensures that:
- February 29 only appears in leap years
- Further validation will be performed by the types used in the keys.
Identity
Two dates are the same if their day of the year and their year are the same.
Converting to code
We use the same as for Gregorian calendar dates.
Python
3 keys
1 BC is represented by 0, and 2 BC by -1, etc.
{
'K1': 1014,
'K2': 10,
'K3': 27
}
JavaScript
3 keys
We will use the following object:
{
K1: 1014n,
K2: 9,
K3: 27
}
Non-positive numbers for K1 represent the years BC, with 0 being 1 BC, -1 being 2 BC, etc.
Renderer
Renderers depend on the language. We will start with a general renderer outputting an ISO string as the default behaviour, i.e. “2014-10-27 CE”, but we will have a configuration that can be adjusted for a given language, e.g. "27 October 2014" or "le 27 octobre 2014 AD".
Parsers
Parsers depend on the language. We will start with a general parser that can take an ISO string as the default behaviour, but we will have a configuration that can be adjusted for a given language.
Alternatives
- We could say we don't need this type, and use the Gregorian calendar date for both Julian and Gregorian calendar dates, and we need to remember which one is what out of context. That's potentially very confusing. It would also mean that the type is syntactically representing dates, but we don't really know what date it is. Also it would contradict what we said on Gregorian calendar date, where we said it means the Gregorian calendar date, and not just the syntactic representation of a date.
- Should we use the Gregorian year, or do we need to introduce a Julian year to shadow the Gregorian year? Unlike with the date, I cannot see a disadvantage of using the same type for the year.
Discussion
Support as proposer --Denny (talk) 14:06, 7 February 2025 (UTC)
Support --Ameisenigel (talk) 20:32, 7 February 2025 (UTC)
Oppose effectively just a duplicate with a really minor semantic difference. Feeglgeef (talk) 15:03, 10 February 2025 (UTC)
- @Feeglgeef: Huh? It's not minor at all! It's up to two weeks off.
- Without Julian calendar representation we won't be able to represent Wikidata dates. --Denny (talk) 19:03, 10 February 2025 (UTC)
- Can we instead have a semantic-free type composed of these two? This would also solve the issue of whether or not gregorian dates are earth-dependent. Feeglgeef (talk) 19:06, 10 February 2025 (UTC)
- What's the point of a semantic-free type on this level? Then you wouldn't be able to answer a question such as "what's the day after x?" or "how long ago was y?" or "what's the day of the week of z?" On a lower level we have semantic free types - such as Z20342 - which are then used to construct the semantic types, such as here. --Denny (talk) 12:50, 13 February 2025 (UTC)
- Can we instead have a semantic-free type composed of these two? This would also solve the issue of whether or not gregorian dates are earth-dependent. Feeglgeef (talk) 19:06, 10 February 2025 (UTC)
Support --99of9 (talk) 21:08, 10 February 2025 (UTC)
Support It's now becoming fundamental also for Z6061. I think it's fundamental to distinguish this type from Z20420 because of the different semantics, while I think it's fine to use Z20159 in this type too (perhaps we should rename it to make it clear that it could also indicate a Julian calendar year). Dv103 (talk) 13:47, 16 June 2025 (UTC)