I've raised a PR that adds the ability to select a format for the timestamp option in the Inject node (and Change node... and any other node using the built-in TypedInput).
Currently, the timestamp option generates a value that is milliseconds since epoch. A common scenario we see is Function nodes then being used to reformat that into some other common representation.
To keep things simple, I'm proposing to offer a short list of commonly useful formats. I'm inviting feedback from the community on what options should be on the list.
Before anyone suggests it, it is feasible to add a 'custom' option that lets the user enter the format string manually... but before going that route, I'd like to make sure we have a good set of built-in choices.
Localisation is a bit of a tricky subject as it requires the node.js runtime locale to be set properly for the end user. That isn't always going to be the case - a cloud hosted instance for example will typically have a locale different to the end user.
It is the type of can-of-worms I'm hoping to avoid for this quick feature
Its a bit meh!!
but if something like this is considered - maybe a check box underneath ("Use Local timezone") instead of a duplicated list, and default to UTC if not detected.
I think the default should be local, in fact I am not sure that the UTC versions are particularly useful. Even the ISO format will generally show local time with timezone.
UTC - we should encourage UTC use mostly since it avoids processing issues. If people have easy options to use local, they are likely to use it and get caught out in the usual date/time processing gotya's.
Please lets keep it simple, this really could easily get out of hand. JavaScript date/time and ISO8601 are obvious and useful choices. Beyond that, you are really getting into design rather than processing choices.
And yes, I'm aware of the irony of me of all people asking for simplicity!
My preference would be local timezone - For me, If I would be using this capability it would be for easy viewing of dates, It would reduce the cognitive load to have it in local time. If I want to do UTC things then i take the time stamp and process it.
We are operating in different time zones so plain local without time zone context has no meaning to us, therefore ISO8601. And if that is in Zulu or Local or whichever timezone doesn't matter, as long as we have that timezone information. (But I'd prefer Zulu time...)
In ISO8601 you have the time zone designator. It can be "Z" for Zulu time (aka UTC) or an offset from UTC. If you omit this zone designator, you should assume that the time is in local time. But then you have no information of what local time, i.e., what the offset from UTC is for that time.
So by omitting time zone designator you get the local time, but without info on what local time.
Writing to database would always be in UTC to avoid problems with clients in different TZ.
I'm sure that's what @TotallyInformation was thinking when writing his previous message.
But most of the users want to open blinds at some local hour.
This is great! After thinking about it a bit, I think that using UTC for these formatting options will only lead to more function nodes, so locale should be used. If the system locale is not set correctly and cannot be changed, or if this is for an app that would have users from different locales, that should be handled the current way through dashboard templates etc.
