Jump to content

Wikifunctions:Type proposals/Day of Roman year

From Wikifunctions

Summary

Day of a Roman year represents an individual day of a Roman calendar year, i.e. a combination of Gregorian / Roman calendar Month and the day of the given month,

Uses

Prompts:

  • Why should this exist?
    • Useful for dates of birth, dates of death, and other events recurring on a specific day of the year
    • Useful for building the Gregorian and Julian calendar date Types
  • What kinds of functions would be created using this?
    • given a Day of the Roman year, what is the day number of that year in a non-leap year
    • what Day of a Roman year follows another?
    • which of two Days of a Roman year are earlier?
  • What standard concepts, if any, does this align with?

Gregorian and Julian calendars

Structure

A Day of a Roman year has two keys:

  1. K1 of Type Gregorian calendar month
  2. K2 of Type Natural number

Example values

This represents Wikipedia day, January 15:

{
  "type": "Day of a Roman calendar",
  "month": "January",
  "day": {
    "type": "Natural number",
    "value": "15"
  }
}

{
  "Z1K1": "Znnn",
  "ZnnnK1": "Z16101",
  "ZnnnK2": {
    "Z1K1": "Z13518",
    "Z13518K1": "15"
  }
}

Validator

The validator ensures that:

  • the day number is within the valid range for the given month

Identity

Two days of a roman year are the same if the day and the month are the same. February 29 is not the same as March 1.

Converting to code

Python

In Python, there is no native Class for the day of the year. Instead we return the following Dict:

{
  'K1': 1,
  'K2': 15
}

We also take such a dictionary back to convert it into a Day of the Roman year.

JavaScript

In JavaScript, there is no native Class for the day of the year. Instead we return the following object:

{
  K1: 0,
  K2: 15
}

Note that as with Gregorian calendar months, months are started to be counted with 0, i.e. January is 0, not 1.

We also take such an object back to convert it into a Day of the Roman year object.

Renderer

The renderer will depend on the language. We will start with a renderer outputting the month number, followed by a “/”, followed by the day number. A configuration object will allow for the easy setting of other renderers for a given language.

Parsers

The parser will depend on the language. We will start with a parser that takes a month number, followed by a “/”, followed by the day number. A configuration object will allow for the easy setting of other parsers for a given language.

Alternatives

  1. Unsure about the name. Day of the Gregorian year could also work.
  2. Not having this type could be an option, and always flatten it out wherever this is needed.
  3. Instead of two keys, we could have one key of natural number, which states the number of the day in the year (e.g. 15 for January 15, or 33 for February 2nd). This has the nuance of handling leap years correctly, which we avoid by splitting it up. Also, having two keys is closer to how most of us think of dates.

Comments

  1. Do we support days that would never be valid (e.g. January 50, February 30)?
    • 1a: Yes, fully support these, expect that of functions
    • 1b: Sort of, Do not outright ban these, but provide no expectation that they be interpreted/received correctly
    • 1c: No, Use a validator to prevent invalid days
  2. If the answer to 1 is A or B, are we sure we want to make what would be the same day, but with a different month, equal
    • 2a: Yes, and February 29 is equal to March 1, February 30 is equal to March 1
    • 2b: Yes, but February 29 is not equal to March 1, February 30 is equal to March 1.
    • 2c: No, Do not support this in the equality function, leave this up to the community.
  3. Should we use integers to represent the day instead of a natural number, to allow for negative dates.
    • 3a: Yes, and if 2a is implemented, include this into the equality function, where March 0 is equal to February 28, and if 2b is implemented, March 0 is equal to February 29. Expect community functions to support this
    • 3b: Yes, and if 2a is implemented, include this into the equality function, where March 0 is equal to February 28, and if 2b is implemented, March 0 is equal to February 29. Do not expect community functions to support this
    • 3c: Yes, but have no effect on the equality function. Expect community functions to support this.
    • 3d: Sort of, but have no effect on the equality function. Do not expect community functions to support this.
    • 3e: No, Use a natural number type instead, but do not have the validator restrict invalid dates above 1
    • 3f: No, have the validator restrict any number above 0
  4. What to call this?
    • 4a: Day of Roman year
    • 4b: Day of Gregorian year
    • 4c: Something else?
  5. How should the renderers/parse work
    • 5a: Separate it with a / for the default renderer and all renderers
    • 5b: Use the common format by the language's local Wikipedia. For English, this would be e.g. 17 January, use a / for the default renderer
    • 5c: Separate with a comma for the default renderer e.g. 1, 17, same as 5b for languages.

Thanks! Feeglgeef (talk) 04:39, 25 November 2024 (UTC)reply

I personally agree with 1b, 2c, 3b, 4a, 5b. Feeglgeef (talk) 04:41, 25 November 2024 (UTC)reply
My personal preferences would be: 1c, although technically start with 1b. I am afraid that 1c is actually kinda difficult. 2c, 3f. 4a. 5b, I guess, but not sure about the default renderer. Most of the decisions can be changed later, so I am going still to implement the type (using natural number instead of integer). --Denny (talk) 18:15, 25 November 2024 (UTC)reply
Our disagreement seems to be about the validator, so it's ok to go ahead and create it for now, but we probably shouldn't have a Validator until we have consensus. Thanks! Feeglgeef (talk) 18:25, 25 November 2024 (UTC)reply
Retrieved from "https://www.wikifunctions.org/w/index.php?title=Wikifunctions:Type_proposals/Day_of_Roman_year&oldid=140901"