Is this a feature or a bug to report?

Forums › Off topic › Is this a feature or a bug to report?

neb

11294 posts

Uber Geek

Trusted

Lifetime subscriber

#300654 25-Sep-2022 22:35

This is meant as a catch-all thread where you've got something that does X in response to Y and you wonder whether it should be doing Z instead, but would like to check with the peanut gallery before opening a case with the manufacturer because it's not immediately clear whether it's a bug or not.

In this particular case it's for the timer on the excellent Midea Cube dehumidifier. During the DST switch it advanced the start and end time by an hour to match the changed clock time, either because it stores time internally as GMT or because someone added code to make sure it'd still run at the same time across DST changeovers.

Problem is I can't decide whether this is a feature or a bug. In this specific case it's a bug because it's supposed to run during the free-power period, but in general, would you expect the time period to run from whatever arbitrary point X pm is each day, so move with DST changeovers, or to always run at the same time, so stay constant across DST changeovers?

Tinkerisk

4224 posts

Uber Geek

#2972863 25-Sep-2022 23:47

If nothing else helps, then UTC (because Greenwich has DST too ;-)

- NET: FTTH, OPNsense, 10G backbone, GWN APs, ipPBX
- SRV: 12 RU HA server cluster, 0.1 PB storage on premise
- IoT: thread, zigbee, tasmota, BidCoS, LoRa, WX suite, IR
- 3D: two 3D printers, 3D scanner, CNC router, laser cutter

fe31nz

1228 posts

Uber Geek

#2972871 26-Sep-2022 00:51

The right way to do this sort of thing is to use UTC internally, and convert all local time values to UTC when used. The key thing here is to keep the local time setting stored, not the UTC setting - just convert to UTC when the time value is used. This avoids all the various and manifold complications of using local time, such as daylight saving. It sounds like the Midea Cube is storing the time settings as UTC, so as well as the local time value of main clock moving an hour forwards with daylight saving, the local time values of the stored UTC settings also moved an hour forwards, which is not what is wanted. This is yet another beginners bug for using times and dates in software. There are many, many others. It should be reported.

neb

11294 posts

Uber Geek

Trusted

Lifetime subscriber

#2972872 26-Sep-2022 01:12

fe31nz:
the local time values of the stored UTC settings also moved an hour forwards, which is not what is wanted.

Well, it's not what I want in this particular case, but it may be what others want. For example if the timer is set to do something at dawn, or dusk, then having it track the changing time of dawn/dusk during winter/summer is a cool feature, not a bug.

And that was my question, is this actually a bug, or is it a feature?

fe31nz

1228 posts

Uber Geek

#2972873 26-Sep-2022 01:30

Unless the manual for the Midea Cube says the timers are for dawn and dusk tracking, then it is clearly a bug. There are devices that can do dawn/dusk - the usual method requires connecting to a server that provides the required times. Calculating it in an IoT device is not usually something anyone would sensibly contemplate. For a start, it requires knowing where the device is currently located, so a GPS receiver would likely be needed. And then it requires knowing what timezone that location is in, and what the current daylight saving time settings are (they change from time to time), so the device needs an Internet connection to get the timezone updates, and so on. The usual solution then becomes to have an Internet connection (since you need that anyway) and get the home base server to deal with all the complications. If the programmers get it wrong, making a change to the home server will fix it for everyone, quite rapidly, rather than requiring all the devices to get a firmware update.