ihucos / counter.dev

Web Analytics made simple

Home Page:https://counter.dev

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Hardcoded utcoffset in client tracker?

Tc-001 opened this issue · comments

commented

Hello!
Love this tool! Really useful to see how my site is doing.

When looking through the client tracker script, this line seemed weird to me: utcoffset: "x"
The number seems to be referring to the dashboard owner's timezone, but then it just seems redundant, as the server already has access to that.

I would guess (but cannot confirm) that it instead would be used to get the client's timezone for use in the "Time" module.
If so, the script to use would need to be something like: utcoffset: (-(new Date()).getTimezoneOffset()/60) (https://stackoverflow.com/a/9149604)

If that is correct, then I can open a pull request and plop it in.
If not, feel free to close this issue.

The number seems to be referring to the dashboard owner's timezone, but then it just seems redundant, as the server already has access to that.

Correct. Loading this information from the db and then saving the tracking data to the db is considerable worse performant than just writing the tracking data because in the request handling we then don't need to wait on the database socket for data being received. I now it sounds maybe a bit weird, but this is the reason we rely on the tracking script to have that number hardcoded.

I would guess (but cannot confirm) that it instead would be used to get the client's timezone for use in the "Time" module.
If so, the script to use would need to be something like: utcoffset: (-(new Date()).getTimezoneOffset()/60)

Now that refers to using the clients - that is the end user's - time zone. But then if the client is from e.G. UTC+14 time zone, that could be up to three two days in the future from the perspective of the counter.dev user. So it may make more sense to show it from the perspective of the dashboard's owner time zone? I don't know, time zones are confusing.

commented

I see, guess makes sense if spinning up the DB is more costly.
Thanks for the explanation!