Bug with Daylight Savings Times

[adampmoss]

There's 100% an issue when setting time rules that overlap daylight savings times.

I have a rule that shows content every other week between 11pm and 11pm on Thursdays every 14 days.

When a daylight savings switchover kicks in on Sunday 29th March at 1am, the following Thursday will incorrectly show my content between the hours of 10pm and 11pm.

I added the following code to debug in rulesShowHTML():

foreach ( $active_periods as $period ) {
            if ( ( $period['start'] <= $right_now_t ) && ( $right_now_t <= $period['end'] ) ) {
                echo get_the_title($id)." active because current time is between ".date('jS F Y H:i:s', $period['start'])."  and ".date('jS F Y H:i:s', $period['end'])."<br /><br />";
                $rule_is_active = true;
                break;
            }
        }

This outputs this on the frontend:

menu1 active because current time is between 2nd April 2020 22:00:00 and 9th April 2020 22:00:00

I think the issue is because we're setting a timezone here:

timed-content/timed-content.php

Line 826 in 56898ce

date_default_timezone_set( $timezone );

When I comment this out the code works as expected. I'm not 100% sure why but I think we want to avoid setting a timezone when working with UNIX timestamps because they should be timezone independent as described here: https://stackoverflow.com/a/23062640/750537

The incorrect setting of the times then gets messed up here in the same getRulePeriods() function:

$instance_start = strtotime( $this->datetimeToEnglish( $instance_start_date,
                $instance_start_time ) . " " . $timezone );    // Beginning of first occurrence
$instance_end   = strtotime( $this->datetimeToEnglish( $instance_end_date,
                $instance_end_time ) . " " . $timezone );            // End of first occurrence

My brain was melting reading this code, I hope you can offer some insight here?

[arnowelzel]

Just some quick thoughts about this issue:

First of all: the times in rules or shortcodes are not unix timestamps but always local times. So the timezone must be used as well. So if we remove the timezone from the calculation at least the current time on the server has to be converted to the local time according to the timezone of the rule.

I think the problem is another: If the start date is before a DST switch, it may move to another time after the DST switch. A workaround might be to add or remove an hour depending on wether the DST of the start date is different to the current date or not.

[adampmoss]

Is this a fix you could implement any time soon? I honestly don't feel like I understand this code or problem well enough to do it at this point.

[adampmoss]

So dumping out the timezone on the frontend in the rulesShowHTML() file I can see that it's set as "UTC", whereas the timezone being used to calculate the time periods is is "Europe/London".

function rulesShowHTML( $atts, $content = null )
    {
        global $post;
        var_dump(date_default_timezone_get());

I'm assuming if we can get the frontend to match the backend that will do the job.

[arnowelzel]

Sorry, but I'm really busy with other things right now. Don't expect a fix within the next 7-10 days.

[adampmoss]

Understood, for the time being I'm going to have to add my fix and comment out line 826 date_default_timezone_set( $timezone );

I'll keep an eye on here for any updates.