this post was submitted on 09 Aug 2023
1916 points (93.0% liked)

Memes

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

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

2023-08-10T20:00:00PT2H30M

[–] [email protected] 3 points 1 year ago (2 children)
[–] [email protected] 3 points 1 year ago

PT, Pacific time. /s

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

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

[–] [email protected] 1 points 1 year ago (1 children)

In my mind, default is UTC unless otherwise specified.

[–] [email protected] 1 points 1 year ago

luckily Local time can be any timezone!

[–] [email protected] 1 points 1 year ago (1 children)

nearly forgot that 8601 has support for durations as well

[–] [email protected] 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