Different date/time format

[VAWVAW]

I would like to have a 24 hour time (%H:%M) and %d.%m date formatting available but I'm not sure whether to add a toggle for both options or just have a format option that links to the available specifiers.

[VAWVAW]

Just changing the format causes problems in format_hourly_forecast_with_width which expects the time to have a certain length.

[BaconIsAVeg]

Sounds like something that should go into the config.yaml as file-only settings.

[BaconIsAVeg]

Do you need %M if they're all :00? That was one of the reasons I removed it. I normally run my terminal with 140 cols but I wanted to at least support smaller widths even if it squishes the location sidebar.

[VAWVAW]

It is necessary for the hourly forecast in the tui. Otherwise you would just have increasing numbers. In my experience, the convention for hours is to either add am/pm or :00 to indicate that it is a time.

[BaconIsAVeg]

True. I'm wondering if a 12/24 hour toggle might be better than allowing a user to specify their own time format.

So instead of 11pm it would be 23:00, I'm sure I can make up that extra character somewhere.

[VAWVAW]

A toggle would probably be best for time but for the date you have at least three different formats:

• mm/dd
• dd.mm
• yyyy-mm-dd

And maybe some scripts consuming the json want to work with unix seconds.

[BaconIsAVeg]

The 24 hour format would be used for sunrise/sunset along with the hourly context data.
The date formats are needed for the 7 day forecast in the context and TUI, which doesn't really need year.

I could include the iso8601 date format the API returns in the hourly and forecast contexts though without too much trouble. It would be in the timezone of the location (as returned my open-metro). I can also add the timezone/utc_offset_seconds from the API response into the context.