How can I configure the Date/Time format this plugin uses when showing the current mesh? It uses us-format which is not used in my country and always irritates me.
So instead of %m/%d/%Y %p I'd like to have it in %d, %m. %Y %H:%M
Thanks in advance for any pointers
I'm sorry my American date format irritates you. I assume you mean the bit of text just above the button of when the last time the mesh was received by the plugin and stored?
So the code is using new Date().toLocaleString() here, which in theory should set the date based on your computer's date/time settings if my understanding of the toLocaleString() is correct.
1 Like
Hi, thanks for replying.
Yes, I mean the date and time after " Using saved mesh data from "
would you mind opening your browser's developer tools (F12) and on the console tab in that run this command and let me know what it returns?
it does in fact return "5/6/2021, 6:41:02 PM" just like the line which bugs me.
Ok, I'm on octopi and may have failed to tweak everything on that raspi, /etc/localtime says
/usr/share/zoneinfo/Europe/Berlin
and /etc/locale.gen has active
de_DE.UTF-8 UTF-8
en_GB.UTF-8 UTF-8
This is actually based on the localization of the settings of the machine that's accessing the web interface, if that is your pi, then you would run sudo raspi-config to set that format I think.
locale
LANG=en_GB.UTF-8
LANGUAGE=
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=
and
date
Thu 6 May 18:47:27 CEST 2021
So there is no m/d/Yhere
Those were the settings of the machine octoprint runs on. The box I'm sitting in front has arch,
locale
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME=de_DE.UTF-8
LC_COLLATE=C
LC_MONETARY=en_DK.UTF-8
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT=en_DK.UTF-8
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
so date shows as
date
Do 6. Mai 19:01:04 CEST 2021
I checked it on an macBook air which is set to German, the line still gives the saved mesh data time in us format. But FireFox console shows "6.5.2021, 19:07:32" for new Date().toLocaleString()
what does new Date().toLocaleString('de_DE') give you?
Yes, that's better, the console returns
new Date().toLocaleString("de-DE")
"6.5.2021, 20:08:43"
Added benefit: giving the desired locale expressis verbis avoids relying on assumptions like "The language version of the browser determines which time format etc. the current user prefers"
And users with en-IE may have installed the default "English" version of the browser but now see it in en-US. That might just be the case here on my arch linux box as firfox is an english version. It still doesn't explain why the same thing happens on the mac.
But that would need a FR on gitHub ?
Edit: checked it on Chrome and the results are the same on the linux box and the mac
Yes, please post a feature request on github, otherwise I'll forget about it.
I 'hacked' the specified locale into the .js at ~/oprint/lib/python3.7/site-packages/octoprint_bedlevelvisualizer/static/js, had to run an Update Mesh to see the change and it works for me.
I want to thank you so much for being that fast to respond and showing me the relevant line of code.
best regards
Array [ "en-US", "en" ] on the linux box, ff
Array [ "de", "en-US", "en" ] on the mac, ff
(4) ["de-DE", "de", "en-US", "en"] on the linux box, cr
(4) ["de-DE", "de", "en-US", "en" ] on the mac, cr
Chrome is actually Chromium on linux
There is no reliable way to determine a user's preferred language or date format without asking them.
Yeah, I've flagged your enhancement request. Will probably add a simple text box to allow entering your language code for this.
saw it, thanks. I believe it may enhance your very useful plugin.
For me personally the greatest help was when you pointed out the line of code and, doing that, indirectly helped me to figure out where plugins are located on octoprint. Thanks again, I learned something.
No problem. Technically you shouldn't modify those files directly but it does work until the next update of a plugin happens. So keep an eye out on release notes for this one. This change is minor enough I may have it available in the next release. I was going to be working on this plugin anyway this weekend.