Wikifunctions:Type proposals/Moment in time

Use/Why

This type would allow for the representation of a moment in time, something critical for many functions. It would allow infinite resolution. Some examples:

• Moment in time to Unix time
• Add to Moment in time.
• Distance between the Earth and Moon at a given moment.

Type

The type created by this proposal would consist of two keys:

1. One key would represent the date of the moment in time, of the Gregorian Calendar Date type
2. one to represent the fraction of the day completed, represented by the Rational number type.

Renderer/Parser

The renderer should display the ISO 8601 representation of the time. The parser should accept and convert one.

Converting to code

This would convert as a 6 key object:

• K1: the year in ISO 8601, int in Python, BigInt in JavaScript
• K2: the month, 1-12 in python and 0-11 in JavaScript
• K3: the day of the month
• K4: the hour of the day, 0-23
• K5: the minute of the hour, 0-59
• K6: the second of the minute, 0-59 (ignore leap seconds, this type implements the "Feeglian calendar" (as named by User:99of9)), would be represented by a rational for infinite resolution.

Timezones

This proposal would not support different timezones, only UTC, because the use cases for timezones should be fulfilled by a different type. This is to provide an objective, accurate, and universal description of time. In the future, a type should be created to handle standard times, instead of moments in time. As such, this type is for representing moments in time, not a time relative to the Earth's rotation or position relative to the sun

Alternatives

• We could replace K4-K7 with one rational number, but this might make it hard to interact with native time types
• We could not use the "Feeglian calendar", but the date type effectively does use the "Feeglian calendar", so we'd be inconsistent with that.

Comments

•  Support as proposer Feeglgeef (talk) 03:17, 26 November 2024 (UTC)
•  Support Jérémy-Günther-Heinz Jähnick (talk) 22:51, 19 January 2025 (UTC)
• My dispute here is not with the format but the interpretation of it. Anything with a Gregorian date, I will interpret as being on the Earth's (sun-based) day matching the one used on Gregorian calendar. Then if leap seconds are added, we do not have to worry that we no longer match with UTC. --99of9 (talk) 09:33, 7 February 2025 (UTC)
• I am in general good with this type, but wonder if it would make more sense to have type for the time of day (since that seems to be a sensible type as well, as it could also be used for other calendars who have a 24 hour time), and then combine this one from Gregorian calendar date and time of day? --Denny (talk) 14:31, 7 February 2025 (UTC)

  I mean, the time of day might just be a wrapper around a single key with a rational number. --Denny (talk) 14:33, 7 February 2025 (UTC)

  Wouldn't this be better as a 0 <= x <= 1 rational type? I see that as very useful. Feeglgeef (talk) 15:08, 7 February 2025 (UTC)

  I am not sure I understand. Do you mean a new rational type restricted to 0 <= x <= 1? --Denny (talk) 07:33, 8 February 2025 (UTC)

  Yes, @Feeglgeef has proposed exactly that at Wikifunctions:Type proposals/Percentage. As I said there, I think we first need to know if there is a better way to constrain input ranges than to make a whole new type. 99of9 (talk) 08:59, 8 February 2025 (UTC)

•  Support --Ameisenigel (talk) 20:25, 7 February 2025 (UTC)
•  Oppose Would become a duplicate of Z6064. Dv103 (talk) 12:55, 6 July 2025 (UTC)