this post was submitted on 26 Jan 2025
333 points (100.0% liked)

196

662 readers
36 users here now

Be sure to follow the rule before you head out.

Rule: You must post before you leave.

^other^ ^rules^

founded 2 years ago
MODERATORS
333
ISO 8601 ftw rule (gregtech.eu)
submitted 4 days ago* (last edited 4 days ago) by lena@gregtech.eu to c/196@lemmy.blahaj.zone
 

!iso8601@lemmy.sdf.org gang, rise up

top 50 comments
sorted by: hot top controversial new old
[–] DankOfAmerica@reddthat.com 1 points 1 day ago

Y'all be riskin it without holocene crypty

SYSM:YY.DM.TzYDY.H.H

4:40.42p EST on Jan 28, 12,025 ->

  • 4120:20.21.-4285.1.6

That's the one that was active when I started typing. However, I change it randomly using the decay of a radioactive isotope that is randomly chosen by the decay of a separate amount of Uranium-238. I'm two randoms in. This way, my time records are always encrypted using open-science source and the government can't hack the pictures of my parking spots at the oncology center to sell them to the NIMBYs at MetAlphabet AI.

[–] fushuan@lemm.ee 61 points 4 days ago (1 children)

"Europe", as if there weren't several languages in Europe with different date formats per language...

load more comments (1 replies)
[–] random@lemmy.blahaj.zone 11 points 3 days ago

I use ss/mm/hh/dd/MM/YYYY

t.european

[–] lorgo_numputz 2 points 2 days ago

This is the way.

[–] nesc@lemmy.cafe 36 points 4 days ago (2 children)

This pyramid visualisation doesn't work for me, unless you read time starting with seconds.

[–] Mirodir@discuss.tchncs.de 20 points 4 days ago (2 children)

A pyramid is built bottom to top, not top to bottom. That's also one of the strengths of the ISO format. You can add/remove layers for arbitrary granularity and still have a valid date.

[–] Zagorath@aussie.zone 24 points 4 days ago

Yeah, but people read top to bottom. The best way to do it would be to have upside down pyramids. With the biggest blocks at the top representing the biggest unit of time (YYYY) and the smallest blocks at the bottom representing seconds & smaller.

load more comments (1 replies)
[–] lena@gregtech.eu 12 points 4 days ago* (last edited 4 days ago) (2 children)
[–] nesc@lemmy.cafe 17 points 4 days ago (1 children)

I get it, just pyramids are misleading, also year-month-day is better because resulting number always grows. 😺

[–] lena@gregtech.eu 5 points 4 days ago (1 children)

A bit out of context, but is your username and instance a reference to nescafe?

[–] nesc@lemmy.cafe 8 points 4 days ago (1 children)

Not really but now that you mentioned it, it will! 😄

load more comments (1 replies)
[–] Zagorath@aussie.zone 13 points 4 days ago (1 children)

2025-01-26T11:40:20, you mean?

load more comments (1 replies)
[–] lazynooblet@lazysoci.al 28 points 4 days ago

I work with international clients and use 2025-01-26 format. Without it.. confusion.

[–] Bo7a@lemmy.ca 22 points 4 days ago (1 children)

I don't know why anyone would ever argue against this. Least precise to most precise. Like every other number we use.

(I don't know if this is true for EVERY numerical measure, but I'm sure someone will let me know of one that doesn't)

[–] endeavor@sopuli.xyz 5 points 3 days ago (1 children)

They are all equally prescise. American one is stupid just like their stupid ass imperial units. European one is two systems slapped together(since they are rarely used together and when they are its the iso format) and iso is what european standard should be.

[–] Bo7a@lemmy.ca 7 points 3 days ago* (last edited 3 days ago) (4 children)

You misunderstand my comment.

I'm saying the digits in a date should be printed in an order dictated by which units give the most precision.

A year is the least precise, a month is the next least, followed by day, hour, minute, second, millisecond.

[–] Umbrias 1 points 2 days ago (3 children)

You are looking not for precision but for largest to smallest, descending order. this is distinct from precision, a measure of how finely measured something is. 2025.07397 is actually more precise than 2025/01/27, but is measured by the largest increment.

[–] Bo7a@lemmy.ca 2 points 2 days ago* (last edited 2 days ago) (1 children)

And to address the argument on precision versus descending. I disagree. An instrument counting seconds is more precise than a machine counting minutes, hours, days, weeks, months etc... And that holds true through the chain. The precision is in the unit.

[–] Umbrias 1 points 1 day ago

the unit is just a report of orientation, not magnitude. if you have a digital counter you are limited by the precision of the digital counter, not the units chosen. an analog measurement however is limited instead by other uncertanties. precision has, genuinely, no direct relationship to units. precision is a statistical concept, not a dimensional one.

[–] Bo7a@lemmy.ca 1 points 2 days ago* (last edited 2 days ago) (1 children)

We can debate this all day. And I can't honestly say that I would take either side in a purely semantics argument.

But the wording comes directly from RFC3339 which is, to me, the definitive source for useful date representation.

https://www.ietf.org/rfc/rfc3339.txt

5.1. Ordering

If date and time components are ordered from least precise to most precise, then a useful property is achieved. Assuming that the time zones of the dates and times are the same (e.g., all in UTC), expressed using the same string (e.g., all "Z" or all "+00:00"), and all times have the same number of fractional second digits, then the date and time strings may be sorted as strings (e.g., using the strcmp() function in C) and a time-ordered sequence will result.

[–] Umbrias 1 points 1 day ago

They chose poor words for this.

[–] Kacarott@aussie.zone 1 points 2 days ago (1 children)

Largest to smallest is also wrong. In 2025/01/28, the 28 is larger than the 01.

It should be "most significant" to "least significant"

[–] Umbrias 1 points 2 days ago (1 children)

largest to smallest is correct. 1 mile is larger than 20 meters. if i had specified numerical value or somesuch, maybe you'd be correct. though significance works as well.

[–] Kacarott@aussie.zone 1 points 2 days ago (1 children)

Largest to smallest is at best ambiguous. It can refer to the size of the number itself, or the size of the unit.

There is a reason this exact concept in maths/computer science is known as the "significance" of the digit. Eg. The "least significant bit" in binary is the last one.

[–] Umbrias 1 points 2 days ago

significance refers to a measurement certainty about a number itself, especially its precision! and is unrelated to the magnitude/scale. the number and dimension "2.5634 mm" has more significant digits than the number "5,000 mm", though the most significant digit is 2 and 5 respectively, and least significant 4 and 5 respectively. this is true if i rewrite it as 0.0025634 m and 5 m. it does work for doing what you say in this case because a date is equivalent to a single number, but is not correct in other situations. that's why i said it does work here.

largest to smallest increment is completely adequate, and describes the actual goal here well. most things are ambiguous if you try hard enough.

load more comments (3 replies)
[–] myrrh@ttrpg.network 17 points 4 days ago (1 children)

YYYY.MM.DD HH.MM.SS, as eru ilúvatar intended

[–] lud@lemm.ee 3 points 3 days ago

YYYY-MM-DD HH:MM:SS

Ftfy

[–] ShareMySims@lemmy.dbzer0.com 17 points 4 days ago (8 children)

Maybe in programming or technical documentation, but no, when I check the date I want to know the day and the month, beyond that, it's all unnecessary information for everyday use, and we have it right in Europe.

You can't change my mind. ¯\_(ツ)_/¯

load more comments (8 replies)
[–] istdaslol@feddit.org 16 points 4 days ago

My stupid ass read this top to bottom and I was confused why anyone would start with seconds

[–] derpgon@programming.dev 14 points 4 days ago

All my homies hate ISO, RFC 3339 for the win.

[–] dkt@lemmy.ml 11 points 3 days ago

finally a correct version of this diagram

[–] azi@mander.xyz 7 points 3 days ago (1 children)

Hot take: 2025-Jan-27 is better than 2025-01-27 in monolingual contexts.

load more comments (1 replies)
[–] PeriodicallyPedantic@lemmy.ca 1 points 2 days ago* (last edited 2 days ago)

I just use millis since epoch

(Recently learned that this isn't accurate because it disguises leap seconds. The standard was fucked from the start)

[–] Gork@lemm.ee 13 points 4 days ago

I often have to refrain myself from using ISO-8601 in regular emails. In a business context the MM/DD/YYYY is so much more prevalent that I don't want to stand out.

Filenames on a share drive though? ISO-8601 all the way idgaf

[–] lolola@lemmy.blahaj.zone 11 points 4 days ago (1 children)

I know, why don't we all agree to agree and use every single possible format within a shared spreadsheet

load more comments (1 replies)
[–] SARGE@startrek.website 10 points 4 days ago (1 children)

In one work report, I recorded the date as "1/13/25", "13/1/25" and "13JAN2025"

I have my preference, but please for the love of all that is fluffy in the universe, just stick to one format....

[–] uis@lemm.ee 1 points 2 days ago

"13.1.25", not "13/1/25".

[–] Track_Shovel@slrpnk.net 8 points 4 days ago (3 children)
[–] uis@lemm.ee 1 points 2 days ago

Wrong format. DD.MM.YYYY.

load more comments (1 replies)
[–] 6mementomorib@lemmy.blahaj.zone 6 points 3 days ago (1 children)

i never saw year first in Europe.

[–] Walk_blesseD@lemmy.blahaj.zone 16 points 3 days ago

You're reading the post backwards.

load more comments
view more: next ›