View Single Post
Old Today, 08:01 AM   #926
thiago.eec
Wizard
thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.thiago.eec ought to be getting tired of karma fortunes by now.
 
Posts: 1,263
Karma: 1419583
Join Date: Dec 2016
Location: Goiânia - Brazil
Device: iPad, Kindle Paperwhite, Kindle Oasis
Quote:
Originally Posted by Feoras View Post
I was afraid this would be a locale thing.

Sadly, this does not work.
What a nightmare. Thanks for the help!

Quote:
Originally Posted by Feoras View Post
Is it really necessary to use lowercase? I think it might be easily missable somewhere which might result in an error. But maybe removing lowercase everywhere will also result in other errors ...

Another idea would be to use a new, forced lower case dict of the month abbreviation list ... like defining a global:
Code:
ml = [month.lower() for month in m]
and then use ml instead of m everywhere, which will result in all data/keys to be lowercase without having to call lower() everywhere. Well, except where the date is obtained from the timezone as in codeblock 2.
And then only use m when displaying it to the user, e.g. in "'">' + m[i] + '</a>'"

----
Anyways, fixing the 2 codeblocks as described above worked for me so far.
Again, thank you so much!
I like the idea of using 'ml' instead of 'm'. I'll check it. In any case, we already have a fix. Thank you very much.
thiago.eec is online now   Reply With Quote