Closed Kriechi closed 4 years ago
I'm torn about this. I do understand where your issue is coming from; I lived through the millennium change and wondered if planes would be falling from the sky. But I want to encourage people to create filenames that are as short as possible. Some firmware simply stops printing if the filename is too long.
I really truly believe that in 80 years time, this plugin will be utterly irrelevant (and so will be 3d printer firmware that can not handle long filenames). Until that time, people can use 20{date_year}
if they feel like it.
How about we compromise on introducing a {date_full}
which uses ISO8601, e.g., it replaces to 2020-06-29
.
This is what I was looking for anyway.
It is such a sliding slope of preferred date formats that I wanted to avoid in the first place by having separate items.... Day before month (like most Europeans are used to)? Dashes between them? Or colons? Time included as well? There is not a single ISO8601 "format".
/sa #13 and #14
Ok, I'll add a {date_full}
that wraps datetime.datetime.now().replace(microsecond=0).isoformat()
I finally decided on {date_iso}
and {time_iso}
, implemented in the above commit.
I'm keeping the issue open until a new version is officially released.
I chose this config option: Prefix:
{date_year}-{date_month}-{date_day}
Expected path:
2020-06-29_test.gcode
Actual path:
20-06-29_test.gcode
Please use full-length 4-digit year representations. The 90's called, they want to work on the Y2K problem again 😄