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

Hard coded time formats should use locale instead #56

Closed
9 tasks done
poblabs opened this issue Feb 4, 2019 · 1 comment
Closed
9 tasks done

Hard coded time formats should use locale instead #56

poblabs opened this issue Feb 4, 2019 · 1 comment

Comments

@poblabs
Copy link
Owner

poblabs commented Feb 4, 2019

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 added a commit that referenced this issue Feb 4, 2019
@poblabs poblabs added the help wanted Extra attention is needed label Feb 4, 2019
poblabs added a commit that referenced this issue Feb 4, 2019
poblabs added a commit that referenced this issue Feb 4, 2019
poblabs added a commit that referenced this issue Feb 5, 2019
poblabs added a commit that referenced this issue Feb 5, 2019
Applies to static or live webpage.

Updates #56
poblabs added a commit that referenced this issue Feb 5, 2019
@poblabs poblabs removed the help wanted Extra attention is needed label Feb 5, 2019
poblabs added a commit that referenced this issue Feb 5, 2019
This improves date time locale format, and makes it easier to extend in future since it's only in 1 place.

Closes #57

Updates #56
poblabs added a commit that referenced this issue Feb 5, 2019
poblabs added a commit that referenced this issue Feb 5, 2019
New Zealand wasn't being picked up since it was en_NZ. Now we replace the `_` with a `-`, so moment.js will look for `en-NZ` and locale format is expected. Also tested with US and DE.

Closes #1

Updates #56
poblabs added a commit that referenced this issue Feb 5, 2019
poblabs added a commit that referenced this issue Feb 6, 2019
@poblabs poblabs changed the title Hard coded time formats should be user changeable Hard coded time formats should use locale instead Feb 6, 2019
poblabs added a commit that referenced this issue Feb 7, 2019
@poblabs
Copy link
Owner Author

poblabs commented Feb 7, 2019

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

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