poblabs/weewx-belchertown

Hard coded time formats should use locale instead

poblabs opened this issue · 1 comments

poblabs commented

Edit: TO DO:

  • Have moment.js take over earthquake formatting
  • Have moment.js take over forecast update formatting
  • Short forecast date (e.g. Tue 2/5 or Tue 5/2 (for the same date depending on locale))
  • Front page weather snapshots day and month in locale from moment.js
  • Update Alert timestamp in belchertown.py
  • Update this <div class="updated">Last Updated to use epoch owned by moment.js
  • Records page
  • Verify all strftime is in locale
  • Highcharts hover not in locale - Apparently highcharts doesn't easily support an %x or %c style for locale formatting on the datetime.) I asked this question after spending a whole day getting nowhere (and ended up finding the answer on my own.

Continued discussion from #1 and #46. I've long thought that the hard coded time formats should be in a user locale or user customizable. This could mean a bunch of new variables though if user customizable is an option. Not pretty - the skin is very variable heavy as it is. Need to try to keep this minimal but functional. Can weewx provide this somehow to Python and moment.js?

Python takes care of the date and time locale pretty well with the month names. Moment.js did not initially, but the latest commit also provides the system locale to moment.js.

Moment.js is used when your page automatically updates in the background when used with MQTT websockets.

Now it's just a matter of month and date formatting. It's different in many locations. Some are Month/Day, others are Day/Month. Some are double digit days (like 04), others are single digit days.

Here are the dates and timestamps used throughout the skin.

  • Long timestamp - February 4, 2019, 11:31:17 am (MQTT updates)
  • Long date - Monday, February 15, 2019 (front page, weather snapshot)
  • Another long date - January 16, 2019, 11:17 AM EST (earthquake)
  • Another long date - February 4, 2019, 11:15 AM (forecast update time)
  • Month and Year - February, 2019 (front page, weather snapshot)
  • Short date - Tue 2/5 (forecast)
  • Simple hour - 6:59 AM (sun and moon)

Then there's the entire Records page to consider.

moment.js formatting and Python's strftime formatting are different. So this could mean 2 variables for each 1 format.

Options are:

  1. Leave it be
  2. Find a happy mix to reduce the number of date formats. The 4 long dates can probably be consolidated into 1 universal long date. Then add them as variables that can be over-ridden by the user.
  3. Use the built-in moment.js and python locale formatting for dates and time.

I think option 3 is probably the best bet. It reduces the number of variables needed to configure.

I'm going to start thinking about this and applying commits against the code to try and satisfy localization of dates and time.

As of faebea5, the 2 below are consolidated into the same format. No variable yet.

  • Earthquake: January 16, 2019, 11:17 AM
  • Forecast Update Time: February 4, 2019, 11:15 AM

Looks like these are what's left to update to locale:

  1. Long timestamp 2 without seconds: January 16, 2019, 11:17 AM (earthquake, forecast update)
  2. Short date for forecast: Tue 2/5
  3. Long date - Monday, February 15, 2019 (front page, weather snapshot)

Month and Year seem to be universal so this might not need a variable?

Need to determine how to have interop between Python strftime and moment.js?

Option 3 would also satisfy a lot of the records page.

Am I making this too hard on myself? Should I be using %x and %c?

Complete:

  1. EDIT Complete in 9cda556 using LL, LTS from moment.js. Long timestamp 1 for MQTT which includes seconds. Important for rapidfire websites: February 4, 2019, 11:31:17 am
  2. EDIT Complete in ee38028 using built in weewx - Hour for sun and moon: 6:59 AM
poblabs commented

With that last commit, I believe all time formats are now using the station's locale. Closing.