this post was submitted on 09 Aug 2023
1829 points (92.8% liked)

Memes

44132 readers
2686 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
1829
2023-08-09.jpg (lemmy.ml)
submitted 11 months ago* (last edited 11 months ago) by [email protected] to c/[email protected]
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 18 points 11 months ago (2 children)

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

2023-08-10T20:00:00PT2H30M

[–] [email protected] 2 points 11 months ago (2 children)
[–] [email protected] 2 points 11 months ago (1 children)

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

[–] GamingChairModel 1 points 11 months ago (1 children)

In my mind, default is UTC unless otherwise specified.

[–] [email protected] 1 points 11 months ago

luckily Local time can be any timezone!

[–] [email protected] 2 points 11 months ago

PT, Pacific time. /s

[–] [email protected] 1 points 11 months ago (1 children)

nearly forgot that 8601 has support for durations as well

[–] [email protected] 1 points 10 months 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