Function Entry: VL-FILE-SYSTIME

← Prev | ↑ Chapter | Next → | Index | Symbols

Function Entry: VL-FILE-SYSTIME

Name

vl-file-systime

Class

Visual LISP File Function

Syntax

(vl-file-systime filename)

Arguments and Values

  • filename: pathname string

Description

Returns the last modification time of the specified file.

Return Values

List or nil.

Both vendors document a seven-element list containing:

  • year
  • month
  • day of week
  • day of month
  • hours
  • minutes
  • seconds

Every engine tested returns an eighth element, milliseconds, so the documented arity is wrong on both sides. The Bricsys page contradicts itself on this point in a single screen: it states the seven-element format and then shows the eight-value sample return (2019 10 4 24 4 1 10 0). Portable code must not assume the length.

Day-of-week numbering

Autodesk states only "Monday is day 1 of day of week, Tuesday is day 2, and so on", and stops. Bricsys states no numbering at all. Critically, no documented example falls on a Sunday, so no reference page pins Sunday down:

Reference page Example date Weekday Documented value
Autodesk 1998-04-08 Wednesday 3
Bricsys V25/V26 2019-10-24 Thursday 4
progeCAD 2011-02-25 Friday 5

Monday through Saturday are therefore 1..6 everywhere, and that is the whole of what the documentation establishes. The engines complete the remaining silence differently (probed 2026-08-09, itself a Sunday):

Engine Sunday Numbering
AutoCAD 2022 runtime 0 C struct tm / POSIX tmwday
BricsCAD V25 and V26 7 ISO-8601

Neither engine contradicts its own documentation — each resolves a gap in it — so this is a divergence of exactly one value.

Reading the day of week portably

Because the divergence is confined to Sunday, and because the two values it takes are 0 and 7, one operation normalises every engine: 

(mod day-of-week 7)

(mod 0 7) and (mod 7 7) are both 0, and Monday..Saturday are 1..6, which mod 7 leaves untouched. So (mod day-of-week 7) yields the POSIX struct tm numbering — Sunday = 0, Monday = 1, … Saturday = 6 — on AutoCAD, on BricsCAD, and on clautolisp under any dialect, without testing which engine is running.

Portable code should therefore read position 3 through mod 7 rather than avoid it. Positions 1, 2, 4, 5, 6 and 7 (year, month, day of month, hours, minutes, seconds) need no such treatment; position 8 (milliseconds) is absent from both vendors' documented arity and must not be assumed present.

Side Effects

None.

Compatibility

Autodesk documents this on Windows and macOS, not Web.

Availability

  • AutoCAD 2026: documented (per Autodesk reference page).
  • AutoCAD 2022: verified by runtime probe 2026-08-09 (eight elements, Sunday=0).
  • BricsCAD V25 and V26: verified by runtime probe 2026-08-09 (eight elements, Sunday=7); the Bricsys DevRef page carries the same text in V25 and in CurVer/V26.
  • Status: verified on both vendors (no longer "presumed compatible").

Source Notes

Notes

  • Autodesk documents a Unicode/LISPSYS behavior change in AutoCAD 2021.

clautolisp

clautolisp implementation deviation — not part of the normative specification above.

  • Arity. clautolisp returns the eight-element list the engines return, not the seven the pages state.
  • Day of week. Monday..Saturday are 1..6, as documented. For the one value the documentation leaves open, clautolisp keeps the POSIX (struct tm) completion, Sunday = 0 — which is also what AutoCAD's runtime does. The bricscad-v25 and bricscad-v26 dialects reproduce their engine's Sunday = 7. This is a case-2 divergence under Chapter 25: the difference is real, each vendor is faithful to its own silence-filling choice, and clautolisp adopts one while the deviant-from-it dialect reproduces the other. Note that the normalisation above, (mod day-of-week 7), collapses the two dialects' values as well — clautolisp code that applies it is insensitive to the selected dialect.
  • Milliseconds. The eighth element is currently always 0. CL:FILE-WRITE-DATE is defined in whole seconds, so the sub-second part of the modification time is not reachable portably, even though the underlying filesystems (APFS, ext4, NTFS) do store it. No probe has yet caught either vendor returning a non-zero value here.