Closed pedrolamas closed 1 year ago
Ah yes that is indeed a miss. I will make sure the right timezone marker is added.
@Donkie This issue still persists. It seems that the local time to UTC conversion is doubled up somewhere. When I edit the spool and set last used to the current time (using the GUI), upon save, it is converted to UTC. The GUI then shows the converted UTC time as local time. Then when you poll the API, the already converted UTC time is then converted again. I will provide screenshots of what I am seeing below.
Set to now (current local time)
Click Save
Spools home page shows converted time
And so does the edit page for the spool
When the API is polled (/api/v1/spool), the result is
Edit: Replaced code block with collapsed section bc the code block made it a readability nightmare Also, this was done on a clean instance of Spoolman
Following up on this Fluidd issue, I have now realized that the date & times returned by the Spoolman API are missing the time zone indicator as per ISO 8601.
Spoolman documentation states that all dates are UTC time zone based, but the serialized representation does not convey that - and I believe this to be incorrect!
For example, calling
/api/v1/spool
, we get a list of spools and I can see the data in all date fields have no time zone indication:As these are all UTC dates & times, these strings should end with a single "Z" - following the ISO and thus solving this issue in Fluidd and any other frontend.
As an example, lets take the first date from that example, "2023-07-30T10:59:52", and assume that my system is using Europe/London time zone which is currently UTC+1 as per British Summer Time.
Here's what I get in JavaScript by using the
Date
constructor:On the first example, as there is no indication of time zone,
Date
will assume that it is on local time and parse and convert to UTC.On the second example, I just suffixed the date with "Z" so that the
Date
constructor understands that I am indeed passing an UTC value, so no conversion is needed.