If you were following this revamp closely so far, you will have seen a bunch of placeholder times. In fact, I am using FIPA SL's time extension to ISO8601 time. The current one just right now in particular being

```
20251226T082013585Z
```
for
> 2025 December 26 8:20am, 13 seconds, 585 milliseconds Zulu time = UTC = GMT.

FIPA SL specifies the time zone suffix of Z for UTC, which is to be prefered. If there is no time zone suffix, times are understood to be local times (do you know where the sender of the local time is... if not you know more now.). My ANSI common lisp to generate this string is

```
(let ((* (multiple-value-list
	  (decode-universal-time 
	   (get-universal-time) 0))))
  (format nil "~@{~?~}"
	  "~10,4,'0r" (list (sixth *))
	  "~10,2,'0r" (list (fifth *))
	  "~10,2,'0r" (list (fourth *))
	  "~a" (list #\\T)
	  "~10,2,'0r" (list (third *))
	  "~10,2,'0r" (list (second *))
	  "~10,2,'0r" (list (first *))
	  "~10,3,'0r" 
	  (list (rem (get-internal-real-time)
		     internal-time-units-per-second))
	  "~a" (list #\\Z)))
```
This result is directly buildable like this in ANSI common lisp, though getting the milliseconds and inserting a `T` in the middle stop it from being too clean. I guess one makes sacrifices for a standard. I chose to shadow the repl's asterisk, since I initially wrote this in terms of lisp's special repl variables. In my opinion, the FIPA SL extension to ISO8601 provides a nice clear target for everyone to slightly unhappily agree to use.

FIPA SL further specifies that if the time is signed, it is a relative time (in which case it would not have a time zone). So

```
-00100000T000000001
```

is ten-years-and-one-millisecond-into-the-past and

```
+00000000T001000000
```

is "in ten minutes". Adhereing to this time standard avoids the calendar notification file format import incompatibility that no-one I have ever met is satisfied with.