lowest_energy_price_today changes at unexpected times and does not stay stable for 24 hours

[itavero]

If I look at the history of sensor.lowest_energy_price_today, I see that it often changes values at 2:00 at night and sometimes even at 14:00 in the afternoon (next to 2:00 on that same day).

The 2:00 might be due to a UTC time being used somewhere instead of local time, but I would never really expect a change during the afternoon. After all, the lowest price for today will be the same the whole day (e.g. from 00:00 to 23:59:59).

[HiDiHo01]

I think it's a UTC error in the code, my history shows only changes at 0:00 https://i.gyazo.com/bf2f8788cff43ce66dc93f2445f4ed02.png I will compare the code with my code later today. Op do 10 okt 2024 10:47 schreef Arno Moonen ***@***.***>:

…

If I look at the history of sensor.lowest_energy_price_today, I see that it often changes values at 2:00 at night and sometimes even at 14:00 in the afternoon (next to 2:00 on that same day). The 2:00 might be due to a UTC time being used somewhere instead of local time, but I would never really expect a change during the afternoon. After all, the lowest price for today will be the same the whole day (e.g. from 00:00 to 23:59:59). image.png (view on web) <https://github.com/user-attachments/assets/a66d60df-418e-4fa6-bcce-bb48a5adaa09> — Reply to this email directly, view it on GitHub <#122>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXDM26ZW4JG25IGREU2HZ7DZ2Y5KDAVCNFSM6AAAAABPWIIGJSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGU3TQMJRG4YTGMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[HiDiHo01]

I think I found it in the models.py code

Original code:

    @property
    def for_today(self) -> bool:
        """Whether this price entry is for the current day."""
        day_start = datetime.now(timezone.utc).replace(
            hour=0, minute=0, second=0, microsecond=0
        )
        day_end = day_start + timedelta(days=1)
        return self.date_from >= day_start and self.date_till <= day_end

My models.py code:

    @property
    def for_today(self) -> bool:
        """Whether this price entry is for the current day."""
        now = datetime.now(timezone.utc).astimezone(
        )  # Convert to local timezone
        day_start = now.replace(hour=0, minute=0, second=0, microsecond=0)
        day_end = day_start + timedelta(days=1)
        return self.date_from >= day_start and self.date_till <= day_end

This will compare now.astimezone() with the list of hours
the replace function sets hour to 0 (which is correct for local not for UTC)
Same for the for_tomorrow() function

Key Differences
Timezone Handling:

Function 1: Uses datetime.now(timezone.utc) to get the current time in UTC and then calculates day_start in UTC.
Function 2: Calls datetime.now(timezone.utc).astimezone() to convert the current UTC time to the local timezone before calculating day_start.

Variable Naming:
Function 1: Directly computes day_start from the UTC time without storing the current time in a separate variable.
Function 2: Stores the current local time in the variable now before computing day_start.

Implications:
Function 1 checks if the price entry is valid in UTC time, which might lead to incorrect results if the application is intended to work in a local timezone context.
Function 2 correctly adjusts to the local timezone, ensuring that the comparison reflects the current day's start and end according to the user's local time.

In summary, the main difference is how each function handles time zones, which can affect the accuracy of the for_today check depending on the intended use case. If the application needs to reflect local time, Function 2 is the more appropriate choice.

Summary:
datetime.now(): Returns the current local time as a naive datetime object.
datetime.now(timezone.utc): Returns the current UTC time as a timezone-aware datetime object.
datetime.now().astimezone(): Returns the current local time as a timezone-aware datetime object, converting a naive datetime to local timezone context.
If you need to work with specific timezones or want more control over timezone handling, consider using libraries like pytz or the zoneinfo module (Python 3.9+).

Correct me if i'm wrong

[itavero]

@HiDiHo01, is your time zone set incorrectly then? Because, I agree that this code seems like the suspect, but that doesn't explain why your installation behaves different then mine?

Perhaps @DCSBL can shed a light on the for_today implementation and whether or not the date time being used there should be updated to the local time or not.

FYI: I was not logged in with my account before (I did do that today). I would expect that to change anything, but that was one thing I could think of that may explain differences.

[HiDiHo01]

My timezone is set to Amsterdam and I use a modified version, see my fork. Logged in or not does not make a difference in time. Op do 24 okt 2024 14:41 schreef Arno Moonen ***@***.***>:

…

@HiDiHo01 <https://github.com/HiDiHo01>, is your time zone set incorrectly then? Because, I agree that this code seems like the suspect, but that doesn't explain why your installation behaves different then mine? Perhaps @DCSBL <https://github.com/DCSBL> can shed a light on the for_today implementation and whether or not the date time being used there should be updated to the local time or not. FYI: I was not logged in with my account before (I did do that today). I would expect that to change anything, but that was one thing I could think of that may explain differences. — Reply to this email directly, view it on GitHub <#122 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXDM265ITF2QCI3JU425WSLZ5DTHHAVCNFSM6AAAAABPWIIGJSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZVGE4DQNBWGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>