1949
2023-08-09.jpg (lemmy.ml)
submitted 1 year ago* (last edited 1 year ago) by Samsy@lemmy.ml to c/memes@lemmy.ml
you are viewing a single comment's thread
view the rest of the comments
[-] FleetingTit@feddit.de 19 points 1 year ago

ISO 8601 ftw. Here's the date, time, and duration for our next meeting:

2023-08-10T20:00:00PT2H30M

[-] Llewellyn@lemmy.ml 3 points 1 year ago
[-] Samsy@lemmy.ml 4 points 1 year ago

PT, Pacific time. /s

[-] Zeragamba@lemmy.ca 2 points 1 year ago

Timezone is optional, and when missing is read as local time.

[-] GamingChairModel@lemmy.world 1 points 1 year ago

In my mind, default is UTC unless otherwise specified.

[-] Zeragamba@lemmy.ca 1 points 1 year ago

luckily Local time can be any timezone!

[-] Zeragamba@lemmy.ca 1 points 1 year ago

nearly forgot that 8601 has support for durations as well

[-] baltakatei@sopuli.xyz 1 points 1 year ago

It handles ambiguity too. Want to say something lasts for a period of 1 month without needing to bother checking how many days are in the current and next month? P1M. Done. Want to be more explicit and say 30 days? P30D. Want to say it in hours? Add the T separator: PT720H.

I used this kind of notation all the time when exporting logged historical data from SCADA systems into a file whose name I wanted to quickly communicate the start of a log and how long it ran:

20230701T0000-07--P30D..v101_pressure.csv

(“--” is the ISO-8601 (2004) recommended substitute for “/” in file names)

If anyone is interested, I made this Bash script to give me uptime but expressed as an ISO 8601 time period.

$ bkuptime
P2DT4H22M4S/2023-08-15T02:01:00+0000, 2 users,  load average: 1.71, 0.87, 0.68
this post was submitted on 09 Aug 2023
1949 points (100.0% liked)

Memes

45889 readers
1246 users here now

Rules:

  1. Be civil and nice.
  2. Try not to excessively repost, as a rule of thumb, wait at least 2 months to do it if you have to.

founded 5 years ago
MODERATORS