View source for Talk:Styleguide Category Updates

== Time and date ==

I would suggest using RFC 3339 or ISO 8601 for dates and time: https://ijmacd.github.io/rfc3339-iso8601/

Well I don't want to use too many punctuation marks. Are you fine with "YYYY.MM.DD - HH:MM (UTC)" as syntax? By the way: Please log in and use your signature so everyone knows who is writing. Thanks!
[[User:Smodd|Smodd]] ([[User talk:Smodd|talk]]) 12:08, 3 December 2023 (CST)

Wouldn't you be using YYYY-MM-DD HH:MM (UTC), not using any periods at all?
I think the version with space between the date and the time is probably more readable to people than the ones with a T there (YYYY-MM-DDTHH:MM), at least. And it is pretty useful to have the dates be unambiguous like that. Especially since the USA'ians often use MM.DD.YYYY.
<br>
[[User:Eleftherios|Eleftherios]] ([[User talk:Eleftherios|talk]]) 15:21, 5 December 2023 (CST)

I am not familiar with a standardized date format for computers that uses dots to separate year, month, and day, so I vote to stick to a widely adopted, readable standard. I propose the following three promising options, so we can move forward with the style guide and adding versions:
# "YYYY-MM-DD HH:MM:SS" (implied to be UTC): This is the original editor's suggestion to use [https://www.rfc-editor.org/rfc/rfc3339 RFC 3339]. It allows for spaces instead of the T and Z separators required in ISO 8601, fitting with [[User:Eleftherios|Eleftherios]]'s suggestion for readability as well.
# "YYYY-MM-DD HH:MM:SS [America/Los_Angeles]": This is the cleanest time zone specification I could come up with, using [https://datatracker.ietf.org/doc/html/rfc9557 RFC 9557]. RFC 9557 is fairly recent (April 2024) and updates RFC 3339 with more readable time zone suffixes. In RFC 3339, "YYYY-MM-DD HH:MM:SS-08:00" would specify Pacific Standard Time, while RFC 9557 lets you specify based on the [https://data.iana.org/time-zones/tz-link.html IANA Time Zone database] name, like "YYYY-MM-DD HH:MM:SS [America/Los_Angeles]" (canonical time zone name) or "YYYY-MM-DD HH:MM:SS [US/Pacific]" (time zone name alias).
#* It is worth noting that the IANA time zone database can change, since it is at the whim of governments changing their time standards and rules. IANA does not appear to keep an updated list of time zone names to reference themselves, but from a quick search I was able to find that the .NET API project, Noda Time, maintains a [https://nodatime.org/TimeZones version archive] of the IANA time zone database going back to 2013, which is probably a sufficiently detailed reference.
# "DD MONTH_WORD YYYY - HH:MM:SS UTC": Conforms with SteamDB, since that is likely where patch/build info will be pulled from anyway. An example is "9 February 2025 - 14:21:21 UTC".

My vote goes for format #1, RFC 3339 (technically conforms to RFC 9557, too). It is a nonambiguous, human-readable datetime standard widely used on the Internet and in computing that is fairly neutral to the formatting preferences of any region of the world (as far as I know). Leading with year, then month, then day also helps with sorting, lexigraphically sorting by year, month, then day. I would discourage allowing time zones other than UTC to minimize the chance of conversion errors, given that SteamDB already uses UTC.

--[[User:Tarlacac|Tarlacac]] ([[User talk:Tarlacac|talk]]) 13:54, 9 February 2025 (CST)