Cloudlog
Cloudlog copied to clipboard
magicbug
Date preference not reflected on Live QSO or Post QSO pages
The date preference specified in the user profile isn't reflected correctly on the Live QSO or Post QSO pages.
The date preference specified in the user profile isn't reflected correctly on the Live QSO or Post QSO pages.
Neither in the QSO widget, as said in https://github.com/magicbug/Cloudlog/discussions/767#discussioncomment-269505
The date preference specified in the user profile isn't reflected correctly on the Live QSO or Post QSO pages.
Neither in the QSO widget, as said in #767 (comment)
QSO Widget should be addressed
Live QSO - I believe this is in footer.php around line 506. With this being the js, I'm not entirely sure how to convert the date format that is stored on the user profile to the js format string without writing a conversion function, or some kind of dictionary/array lookup.
Post QSO - Appears to be in index.php around line 45. The math that it is completing on 45/47 I don't completely understand. When will server time ever be 24+ hours (86,400 seconds) off of UTC time? I don't understand the use of the hidden fields between lines 53-57 either, but they appear to only be used on Live QSO and not related to this issue directly as far as I can tell.
@T012m3n7oR Yeah, that is correct. I don't know how to do this in JS, that's why I haven't fixed it. I don't know if @magicbug knows either.
If I remember correctly, the calculation that is done, is to check if the stored date is less than 24 hours old. if it is, use it, if not use current.
@AndreasK79 I actually just fixed this locally. You can call PHP in the middle of the JS... so it's definitely dirty, but you can use that to look up the user's setting, and then I'm doing str_replace to replace the values to the jclock equivalents.
I've since tested a few different time formats with the saving QSO post and Live pages and they still seem to work without issue.
I'll PR probably within the next hour or two.
Edit: Or not.. The problem with my previous PR is it's pulling from my Master branch, and even though I told the new branch to start from an earlier commit apparently Github still sees the other changes as part of the new branch, which would force them into the repo if this one is accepted. I'll have to wait for the other PR to be reviewed and then hard pull into my repo so I can start from scratch to get it back on track for branches.
@T012m3n7oR guess we solved that PR problem. Great that you found a solution, even though it's a dirty fix.