Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Date translation problem #8219

Open
stucka opened this issue Jan 30, 2024 · 2 comments
Open

Date translation problem #8219

stucka opened this issue Jan 30, 2024 · 2 comments

Comments

@stucka
Copy link

stucka commented Jan 30, 2024

Describe the bug
Within reports/daily stats tonight:
At night I seem to be getting a day-of-the-week response based in UTC or where the server is hosted, but I'm getting a calendar-day response from my local time.

I see for example "Tuesday, 1/29/2024" -- Tuesday belonging to the latest date in the server location, and 1/29 belonging to my location. 1/29/2024 is a Monday.

To Reproduce
I suspect this problem will look different in the morning when the dates appear to be the same.

Expected behavior
There is a mismatch in day-of-week reporting and calendar-date reporting when the remote date is different from the local date.

Screenshots
Will attach from my phone in a comment.

Your setup information
Nightscout 15.0.2
Sharebridge

Additional context
I believe the problem is in /lib/report_plugins/utils.js, with some unnecessarily complex day-of-week hardcoded that will also break translations. The handling for the day-of-the-week is different than the handling for the localized date, but both can be handled in the same way.

However, I am getting readings for the actual Tuesday, 1/30/2024, here in my living room where it's Monday, 1/29/2024. Any fix would need some testing.

That said, however, if a localized date string is what makes sense here, then the answer might be to rip out the hard-coded day-of-week lookup array and let toLocaleDateString handle the full translation.

(for testing: var date = new Date() )

ret = date.toDate().toLocaleDateString({weekday: "long", month: "numeric", day: "numeric", year: "numeric"});

Sample runs:
date.toLocaleDateString("en-US", {weekday: "long", month: "numeric", day: "numeric", year: "numeric"})
"Monday, 1/29/2024"
date.toLocaleDateString("de-DE", {weekday: "long", month: "numeric", day: "numeric", year: "numeric"})
"Montag, 29.1.2024"

I had a little bit more information here: #8176 (comment)

@stucka
Copy link
Author

stucka commented Jan 30, 2024

Screenshot_20240129-212723

@stucka
Copy link
Author

stucka commented Jan 30, 2024

The next morning's is not actually better.
Screenshot_20240130-044452

At the moment there are 0 readings for "Wednesday 1/30/2024", which again does not exist; 116 readings for "Tuesday 1/29/2024", and 287 for "Monday 1/28/2024". At this moment, in my local time and in GMT, it is Tuesday, 1/30/2024.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant