Feedback: Adding format options to 'timestamp' Inject option


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.

Comments here or on the PR (linked below)...



What about toLocaleString ?

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 :slight_smile:

We can consider a list of options for toLocaleString like "en-gb", "fr-fr"...

The function accept local string so no env needed

Adding an output of a native Date object can be useful.
usually this is done in a function node new Date(msg.payload)

A small thing of course - but can reduce the need downstream

I can see @Steve-Mcl has already requested this on the PR :smile:

For the last three options are those UTC or local timezone?

What do you want it to be? I'm looking for feedback and ideas at this stage.

Congratulations on the can of worms Nick :wink:

Screenshot 2023-12-04 at 18.23.36

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.

1 Like

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.

1 Like

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! :sunglasses:


In that case I don't think we should provide the options that do not include the timezone. It will just cause confusion and additional traffic here.

1 Like

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.

Good idea btw

I have difficulty seeing a use case for HH:mm:ss in UTC. Or YYYY-MM-DD.

1 Like

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...)

1 Like

ISO8601 is always in UTC.

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.

It can be something like
which is effectively local time and offset.

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.

1 Like

So used to using it that I forgot you can change the TZ. :slight_smile: Because most people sensibly use it in UTC. :grinning:

1 Like

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.