Infinite season: how-to?

Indeed,
it is not possible to have yearles seasons.
Perhaps I tried this, but did not find a way to make the Year optional.
Instead, you must create some year-seasons in advance.
Of course, you can re-use a past season, by simply changing the past year in a future year.

Do you think the help text should be improved?
Or do you want to make this a feature request?

In database start and end hours is created as INT(11)

  `field_opening_hours_starthours` int(11) DEFAULT NULL COMMENT 'From',
  `field_opening_hours_endhours` int(11) DEFAULT NULL COMMENT 'To',

The maximum timestamp that can be stored in an INT(11) is 2147483647 (Tue Jan 19 2038 03:14:07 GMT+0000)

if I enter "Jan 19 2038" as the season end date, in the database I see 2147468400, so the conversion does not take the timezone into account

2147468400 is:

• Mon Jan 18 2038 23:00:00 GMT+0000
• Tue Jan 19 2038 00:00:00 GMT+0100

but this could be another issue...

For infinite seasons, it would be enough to set the end date to January 18, 2038 (to avoid problems with the timezone), in this way the season will be practically always visible.

It would be useful to have a "make infinite" checkbox in the widget that automatically sets a start date in the past and an end date set to the timestamp 2147483647 when saved.

This is a sort of workaround, but I think it can work for the purpose

@johnv sorry for my responding so late. I was just about to say, yes, let's clarify the help text.

@robertom thanks for your idea. Appealing idea at first, I gave it a quick try but on second glance: for just 1 "infinite" season of course we can already enter the default office hours. Any "New season" entered afterwards requires start and end dates.

So as long as we cannot define yearless periods, I'd still suggest to change the text:

"Allows to register weekly opening hours for seasons, like 'Summer 2025'. This requires the Extended Weekday Widget."

@hexabinaer does your formatter display the start and end date of the season? Because if it doesn't, setting fake dates should work around the problem

I am testing the module for a project and in my tests I set:

• Summer season: from 14/01/2025 to 18/01/2038
• Winter season: from 14/01/2025 to 18/01/2038

and with the table formatter I get

Currently there is no possibility, but it would be useful to have an option to not show the default office hours

In the screenshot, my formatter is configured to show only the opening dates... it's part of my tests, but basically it doesn't change that this method can potentially be used (if your formatter doesn't show the season date range)

I am not sure of your use case.
Would you like to show at the same time the Summer and Winter times?
Or would you want to alternate, depending on the current date?

Do you have a mock-up or screenprint of the desired situation? I can imagine to have the dates empty in the widget, or to hide the dates in the theming.

Sorry, I entered my last comment in an old, not-refreshed page, so I missed the comments from 14-1-2025.

Indeed, you can just add 2 seasons from 1-1-2020 until 1-1-2038 (my database supports 2099, too).
Both seasons are displayed. The dates are not displayed in the formatter by design.

You cannot change the 'Day' caption, into season name. From the given screenshot, the 'Day' caption should be hidden (plz create a issue for that if needed - there is already a 'Show the hours, even when fully empty' formatter setting).

Ha, now the penny has dropped :-)

I understand it's possible to simply display 2 seasons with opening hours. I forgot to mention that we do want to used the "Currently open/closed" status. And that's what does not work with this workaround.

Our platform deals with user-generated content. A typical user enters opening hours + exception days for a museum (default w/o seasons). Others enter information for an open air cinema, only open in the summer months. And some users maintain information about a point of interest that has regular (differing) summer + winter opening hours.

"Now open" will be the base filter for a map view.

I was just curious if I've missed some hack before writing a handout add-on. To keep the service up now we need make users understand that they need to update once a year.

In my test site, i now have a node with 2 identical/overlapping seasons.

I cannot garantie that the NowOpen indicator is flawless in this situation.

Yeah, I guess a yearly review of the opening times is best practice.
The, make sure you set the horizon for excdptions and season properly.

Alyernatively, user may maintain the summer season for 3 or more years ahead.

Or we should give some specificeer years a special 'repetitive' meaning.

Or we should Explorer the year-less date alternatives (IIRC, i stumbles cross such a core issue)