In simpletime node 'mydoy' does not increment at 00:00

General
1

I use the 'simpletime' node in many of my flows.
This node can also output the day-of-year as msg.mydoy .

However, I noticed that mydoy does not increment at 00:00 but at 01:00

How can I correct this ?

2

Hi @GammaKappa

I don't use this Node, but it seems very possible, it based on UTC time?

If no date is provided, it will use a new Date object... and a new Date object is:

JavaScript Date objects represent a single moment in time in a platform-independent format. Date objects encapsulate an integral number that represents milliseconds since the midnight at the beginning of January 1, 1970, UTC (the epoch ).

@Paul-Reed may be able to confirm this

3

If you output mytime from the simpletime node, is the time correct for you?

I would suspect that the most likely cause is the time or timezone is different on the node-red server where node-red is running, to where your browser is running.
Are you running docker?

1 Like
4

I am running node-red on a Raspberry Pi (no docker).

Time Zone on the Pi is set to Europe-Brussels.
The 'mytimes' output shows the correct time.

5

It is probably best to submit an issue on the node's github page.

6

I just did a little test my altering my system time and the msg.myday seems to be in sync with other properties when crossing a midnight boundary.
image

I'm in London/Europe UTC+1 timezone

Can you show us a debug output that demonstrates us the problem your having?

7

Here's an excerpt from a log file :

image

@cymplecy : my problem is with 'mydoy' rather then 'myday'

9

Sorry for not reading your original post properly :frowning:

I am getting the same issue as you

image

[edit] I'm thinking this issue probably comes from this bit of JS code in the node source

ny = Math.ceil((d - new Date(d.getFullYear(),0,1)) / 86400000)

A bit of googling suggests it should be more like this

ny = Math.floor((d - new Date(d.getFullYear(), 0, 0)) / 86400000)

but I'll do some testing to see if works before submitting it as a fix
[edit2]
Initial testing seems to indicate that both pieces of code return same result so having to go deeper down the rabbit hole :slight_smile:

10

I use this:

function getDayOfYear(dt){
    return (Date.UTC(dt.getFullYear(), dt.getMonth(), dt.getDate()) - Date.UTC(dt.getFullYear(), 0, 0)) / 86400000
}

Demo
image

2 Likes
11

That looks like just another way of the google provided solution but avoiding have to use Math.floor :slight_smile:
I think all the code snippets are producing the same number but something is going amiss somewhere

My thoughts at this point is that it's some sort of timezone issue but as you know - I'm no JS expert :slight_smile:

Aside - I had written a DOY function in another language (Snap!) and was using that to cross-check but I've found out that is giving the wrong answer as well! (Separate un-related issue)

12

As would pretty much any working solution - I dont understand your point?

There is a good reason for avoiding floor - the solution needs to remove traces of DST and TZ then do the calculation.

what i said :point_up: which is why this uses UTC and not floor

13

An alternative way would be to subtract or add the timezone offset (which in essence is what the above does without calling getTimezoneOffset)

14

Lastly, if moment is available, then

moment(dt).dayOfYear()
15

My point was that your solution was logicaly the same as the google one) and therefore the algorithm itself is probably not at fault - no offence intended :slight_smile:

16

simpletime node is the lean machine used to avoid moment :slight_smile:

1 Like
17

Lastly, I would add, a set of unit tests in the node should check the solution (mine too) to ensure leap years, start of year, end of year etc all make sense (and multiple timezones too)

18

I think that is somewhat superfluous since Node-RED installs moment by default :person_shrugging:

The node could make use of moment without actually adding it in the package (or at least make it a peer dependency) - but probably best to avoid it.

19

I thought moment was deprecated-so relying on it being in the core while good for now, may not be a totally valid assumption.

2 Likes
20

Does seem to give the correct answer for all just before midnight/just after midnight including end of year scenarios

Thank you :slight_smile:

image

I'll make a PR to @Paul-Reed (done)

I'm giving up trying to understand why the other ones don't work and just stop while I'm behind

Aside - and I've fixed my issue in Snap! which uses an entirely different method
(Basically specify how many days in each month adjusted for leap years and add in the DD value of YYMMDD)

image
(Snap! is 1-based indexing hence the need for the +1 and -1 here and there)

2 Likes
21

Thanks @cymplecy
I'm out all day, but back this evening and will catch up then.

1 Like