< and > does not work in rule when comparing time

[mackowiakp]

I use at least one year such rule for dim LCD display via PWM:

On LCD_DIM do
 if %systime% > 20:00 or %systime% < 6:00 and [VAR#9]=1 and [VAR#10]=0 and %sysyear% > 2000
   event,display_off
 endif
EndOn

It does not work in mega-20191108. If I remove %systime% comparison, it works. Moreover if I use %syssec_d% instead %systime%, it works correctly too. The problem is that I use similar comparisons in practically all my ESP units. Strange is that the rule above dim display at 21:00. Last month there was a change of time to winter. So it looks like comparison is done according to summer time.

[TD-er]

Hmm that's unlikely it is a DST issue. More likely I messed up in the rules handling.

Can you test with using %systm_hm% instead of %systime% ?

[giig1967g]

@mackowiakp Isn't there a limitation of 3 comparison in an "if" statement? In your code I count 5 comparisons.

[TD-er]

@giig1967g I don't think there is a limitation on the number of items here. I do think it does not match the HH:MM:SS and HH:MM as time notations, so that's why I suggested to test with %system_hm% since that has a HH:MM notation.

In the debug log, there should be more info displayed on how that line is being checked. So that's multiple lines of log output showing it step-by-step.

@mackowiakp can you show some of these logs?

[mackowiakp]

Extremely strange. Actual time is 6:20, and it works correctly. That means that in line: %systime% > 20:00 or %systime% < 6:00 and [VAR#9]=1 and [VAR#10]=0 and %sysyear% > 2000 the comparison %systime% < 6:00 works good. At this moment can not check first comparison that is %systime% > 20:00. Works properly with single digit hour but not with double? Dont know at this moment. Will test during the day whats going on, because reliable test can be done only with NTP synced not by force non-real time. And will post logs if available. But yesterday between 20:00 and 21:00 I tested such comparisons: %systime% > 20:00:00 and %system_hm% > 20:00. Both does not work properly. Sorry, forgot about logs. Of course comparison with amount of seconds from the beginning of day, worked properly. And of course all system time-related variables have proper values all the time (as system variable list stands). One more remark. FW based on mega-20191108, cutom buid because I use sensor not included by default in ready bin`s of actual release.

[ghtester]

Perhaps a simple fake NTP server python script could help with debugging? https://github.com/olavmrk/fake_ntp_server

[uzi18]

or change location from +1 to +20

[mackowiakp]

Let's not hurry. It's 8:10, we'll wait until 10:01, the first attempt then at 13:01 and the final evening. I don't like to test in "forced" conditions. Testing in real conditions takes a bit longer but is more reliable. Because it is not known if the bug elsewhere. too.

[giig1967g]

@TD-er I am reading it in the wiki: https://www.letscontrolit.com/wiki/index.php/Tutorial_Rules#AND.2FOR "Up to two AND/OR can be used per if statement, that means that you can test three float values and if the statement is true/false corresponding action will take place."

[TD-er]

@TD-er I am reading it in the wiki: https://www.letscontrolit.com/wiki/index.php/Tutorial_Rules#AND.2FOR "Up to two AND/OR can be used per if statement, that means that you can test three float values and if the statement is true/false corresponding action will take place."

I think that's a bit outdated, since the current routine is a bit more flexible. See the function conditionMatchExtended , which does perform a do .. while loop as long as there are and or or statements in the code.

[mackowiakp]

Houston, we have a problem.

I change rule for test purposes to:

if %systime% > 10:30 or %systime% < 6:00 and [VAR#9]=1 and [VAR#10]=0 and %sysyear% > 2000

And it dim display at 11:31, according to summer time Than I change it to:

if %systm_hm% > 12:01 or %systm_hm% < 6:00 and [VAR#9]=1 and [VAR#10]=0 and %sysyear% > 2000

At this moment is 12:04 but display is not dim. Probably will be dim at 13:02. All we know that time dependencies are essential for control.

[TD-er]

Is your timezone at +60 minutes? Can you change the timezone to see if you can reproduce this behavior? (like @uzi18 suggested)

[mackowiakp]

Is your timezone at +60 minutes?

See screenshots below. I live in Gdynia/Poland so TZ is the same like in Amsterdam or Stockholm. System variables shows correct values.

Can you change the timezone to see if you can reproduce this behavior? (like @uzi18 suggested)

Of course. But after 13:02. Will see what happens

[mackowiakp]

Yup, so we have 13:02, display is dim at least 1 min and a rule looks like:

if %systm_hm% > 12:01 or %systm_hm% < 6:00 and [VAR#9]=1 and [VAR#10]=0 and %sysyear% > 2000

OK. What parameters You want me to change for proper test?

[TD-er]

Can you collect some of the log in debug mode when parsing this line? Maybe also add a logentry line showing the same as your if statement line. For example:

logentry,'if %systime% > 20:00 or %systime% < 6:00 and [VAR#9]=1 and [VAR#10]=0 and %sysyear% > 2000'

[mackowiakp]

logentry in debug mode is a bit problem. I have connected (that is solder) proximity sensor acting as switch. So there will be a flood of logs. Will try to filter something interesting. BTW. There should be possibility to log it to the file. Useful in such cases.

[giig1967g]

@mackowiakp why are using this check? and %sysyear% > 2000

If you just want to check if NTP time has been set, you could use and %isntp% = 1

[TD-er]

logentry in debug mode is a bit problem. I have connected (that is solder) proximity sensor acting as switch. So there will be a flood of logs. Will try to filter something interesting. BTW. There should be possibility to log it to the file. Useful in such cases.

You can disable that plugin.

[mackowiakp]

@giig1967g. Because of historical reasons. I dont remember exactly version number when I started play with ESPeasy, but I notice at this time some problems with %isntp%. Dont remember at this moment what was it the problem but the workaround was to use %sysyear% > 2000. And I just use it for near two years with proper result.

[mackowiakp]

You can disable that plugin.

OK. But the test will not be provided in real working hardware/software. But will try.. Be patient, will post results ASAP.

[ghtester]

BTW. There should be possibility to log it to the file. Useful in such cases.

You may configure ESP_Easy logging to syslog server. https://www.ittsystems.com/best-free-syslog-server-windows/

[mackowiakp]

So You have. Using line: logentry,'if %systime% > 16:00 or %systime% < 6:00 and [VAR#9]=1 and [VAR#10]=0 and %sysyear% > 2000'

Below, log config and logs from 15:59 to 16:01. There is nothing special concerning LCD_DIM event. Of course, display not dim at 16:00 and 1-3 sec. But it should. BWT. I use taskrun to run task containing dummy sensor. Its fixed now but not relesed yet. So I would not able to compile own build with sensor which is not present in release. by default.

LOGS:

Logging: Debug (3)
46372750: DS: SP: 56,1,55,5,7f,a5,a5,66,fc,OK,7
46372750: DS : Temperature: 21.37 (28-fa-2-94-97-2-3-ee)
46372752: EVENT: Temp-Piotr#Temperatura-Piotr=21.37
46372889: ACT : TaskValueSet,1,3,21.37
46372896: Command: taskvalueset
46372943: ACT : LCD,4,1,Wewn. 21.4° VOC 999
46373117: Domoticz: Sensortype: 1 idx: 126 values: 21.37
46380365: Dummy: value 1: 5.60
46380366: Dummy: value 2: 1016.00
46380366: Dummy: value 3: 21.37
46380366: Dummy: value 4: 6.80
46380367: EVENT: Temp+Baro#Temp=5.60
46380485: ACT : TimerSet,4,300
46380491: Command: timerset
46380497: ACT : LCD,2,1,Pn.5.6° Pd.6.8°
46380575: ACT : LCD,3,1,Ciśnienie 1016hPa
46380729: EVENT: Temp+Baro#Baro=1016.00
46381359: ACT : Let,1,0
46381364: Command: let
46381367: ACT : event,LCD_REFRESH
46381372: Command: event
46381373: EVENT: LCD_REFRESH
46381467: ACT : LCD,1,1,15:59 Wt. 12/11/19
46381642: ACT : event,LCD_DIM
46381648: Command: event
46381648: EVENT: LCD_DIM
46381819: ACT : Let,1,1
46381825: Command: let
46381829: ACT : SendToHTTP,192.168.0.25,8080,/json.htm?type=command¶m=switchlight&idx=124&switchcmd=On
46381836: Command: sendtohttp
46381837: SendToHTTP: Host: 192.168.0.25 port: 8080
46384201: HTTP: TaskValueSet,1,1,5.6
46384203: Command: taskvalueset
46384297: HTTP: TaskValueSet,1,4,6.7
46384299: Command: taskvalueset
46384381: HTTP: TaskValueSet,1,2,1016
46384383: Command: taskvalueset
46384427: HTTP: TaskRun,1
46384428: Command: taskrun
46385197: WD : Uptime 773 ConnectFailures 0 FreeMem 17152 WiFiStatus 3
46415197: WD : Uptime 774 ConnectFailures 0 FreeMem 17176 WiFiStatus 3
46440357: Dummy: value 1: 5.60
46440358: Dummy: value 2: 1016.00
46440358: Dummy: value 3: 21.37
46440358: Dummy: value 4: 6.70
46440359: EVENT: Temp+Baro#Temp=5.60
46440482: ACT : TimerSet,4,300
46440489: Command: timerset
46440494: ACT : LCD,2,1,Pn.5.6° Pd.6.7°
46440565: ACT : LCD,3,1,Ciśnienie 1016hPa
46440689: EVENT: Temp+Baro#Baro=1016.00
46440853: EVENT: Temp+Baro#Temp-Piotr=21.37
46441060: EVENT: Temp+Baro#Temp-Pld=6.70
46441236: EVENT: Clock#Time=Tue,16:00
46441311: ACT : Let,2,3
46441317: Command: let
46441325: ACT : Let,1,0
46441330: Command: let
46441333: ACT : event,LCD_REFRESH
46441338: Command: event
46441339: EVENT: LCD_REFRESH
46441470: ACT : LCD,1,1,16:00 Wt. 12/11/19
46441646: ACT : event,LCD_DIM
46441652: Command: event
46441653: EVENT: LCD_DIM
46441855: ACT : Let,1,1
46441861: Command: let
46441864: ACT : SendToHTTP,192.168.0.25,8080,/json.htm?type=command¶m=switchlight&idx=124&switchcmd=On
46441872: Command: sendtohttp
46441873: SendToHTTP: Host: 192.168.0.25 port: 8080
46442835: DS: SP: 56,1,55,5,7f,a5,a5,66,fc,OK,7
46442835: DS : Temperature: 21.37 (28-fa-2-94-97-2-3-ee)
46442838: EVENT: Temp-Piotr#Temperatura-Piotr=21.37
46442957: ACT : TaskValueSet,1,3,21.37
46442964: Command: taskvalueset
46443017: ACT : LCD,4,1,Wewn. 21.4° VOC 999
46443156: Domoticz: Sensortype: 1 idx: 126 values: 21.37
46444056: HTTP: TaskValueSet,1,1,5.6
46444057: Command: taskvalueset
46444145: HTTP: TaskValueSet,1,4,6.7
46444146: Command: taskvalueset
46444227: HTTP: TaskValueSet,1,2,1016
46444229: Command: taskvalueset
46444266: HTTP: TaskRun,1
46444268: Command: taskrun
46445197: WD : Uptime 774 ConnectFailures 0 FreeMem 17152 WiFiStatus 3
46462070: HTTP: event,alive
46462162: EVENT: alive
46462210: ACT : timerSet,7,1000
46462216: Command: timerset
46475197: WD : Uptime 775 ConnectFailures 0 FreeMem 17176 WiFiStatus 3
46500366: Dummy: value 1: 5.60
46500367: Dummy: value 2: 1016.00
46500367: Dummy: value 3: 21.37
46500367: Dummy: value 4: 6.70
46500368: EVENT: Temp+Baro#Temp=5.60
46500486: ACT : TimerSet,4,300
46500492: Command: timerset
46500499: ACT : LCD,2,1,Pn.5.6° Pd.6.7°
46500569: ACT : LCD,3,1,Ciśnienie 1016hPa
46500692: EVENT: Temp+Baro#Baro=1016.00
46500859: EVENT: Temp+Baro#Temp-Piotr=21.37
46501027: EVENT: Temp+Baro#Temp-Pld=6.70
46501245: EVENT: Clock#Time=Tue,16:01
46501319: ACT : Let,2,3
46501325: Command: let
46501333: ACT : Let,1,0
46501338: Command: let
46501340: ACT : event,LCD_REFRESH
46501346: Command: event
46501346: EVENT: LCD_REFRESH
46501440: ACT : LCD,1,1,16:01 Wt. 12/11/19
46501652: ACT : event,LCD_DIM
46501658: Command: event
46501659: EVENT: LCD_DIM
46501860: ACT : Let,1,1
46501865: Command: let
46501869: ACT : SendToHTTP,192.168.0.25,8080,/json.htm?type=command¶m=switchlight&idx=124&switchcmd=On
46501876: Command: sendtohttp
46501877: SendToHTTP: Host: 192.168.0.25 port: 8080
46504060: HTTP: TaskValueSet,1,1,5.6
46504061: Command: taskvalueset
46504172: HTTP: TaskValueSet,1,4,6.7
46504174: Command: taskvalueset
46504241: HTTP: TaskValueSet,1,2,1016
46504243: Command: taskvalueset
46504276: HTTP: TaskRun,1
46504278: Command: taskrun
46505210: WD : Uptime 775 ConnectFailures 0 FreeMem 17152 WiFiStatus 3
46512659: DS: SP: 55,1,55,5,7f,a5,a5,66,39,OK,7
46512659: DS : Temperature: 21.31 (28-fa-2-94-97-2-3-ee)
46512662: EVENT: Temp-Piotr#Temperatura-Piotr=21.31
46512780: ACT : TaskValueSet,1,3,21.31
46512788: Command: taskvalueset
46512841: ACT : LCD,4,1,Wewn. 21.3° VOC 999
46512979: Domoticz: Sensortype: 1 idx: 126 values: 21.31

[mackowiakp]

You may configure ESP_Easy logging to syslog server. https://www.ittsystems.com/best-free-syslog-server-windows/

I use rsyslogd on my NAS

[TD-er]

I don't see any && or || in the logs. See the code here: https://github.com/letscontrolit/ESPEasy/blob/510afb2553b28501db5f5bc0de761c1eb851e2cf/src/ESPEasyRules.ino#L684-L747

Do you have a build which does not have debug logs included?

[mackowiakp]

No. I just commented in define_plugin_sets.h some drivers and added 2 other. That is PMS Dust Sensor and FM radio. And than compile as NORMAL. Below changes I made in this file: All the rest is the same as in official the last release.

// STABLE #####################################
#ifdef PLUGIN_SET_STABLE
    #define USE_SERVO

    #define USES_P001   // Switch
    #define USES_P002   // ADC
    #define USES_P003   // Pulse
    #define USES_P004   // Dallas
    #define USES_P005   // DHT
    #define USES_P006   // BMP085
//    #define USES_P007   // PCF8591
    #define USES_P008   // RFID
    #define USES_P009   // MCP

    #define USES_P010   // BH1750
    #define USES_P011   // PME
    #define USES_P012   // LCD
    #define USES_P013   // HCSR04
    #define USES_P014   // SI7021
    #define USES_P015   // TSL2561
//    #define USES_P016   // IR
    #define USES_P017   // PN532
    #define USES_P018   // Dust
    #define USES_P019   // PCF8574

    #define USES_P020   // Ser2Net
    #define USES_P021   // Level
    #define USES_P022   // PCA9685
    #define USES_P023   // OLED
    #define USES_P024   // MLX90614
    #define USES_P025   // ADS1115
    #define USES_P026   // SysInfo
    #define USES_P027   // INA219
    #define USES_P028   // BME280
    #define USES_P029   // Output

//    #define USES_P030   // BMP280   (Made obsolete, now BME280 can handle both)
    #define USES_P031   // SHT1X
    #define USES_P032   // MS5611
    #define USES_P033   // Dummy
    #define USES_P034   // DHT12
//    #define USES_P035   // IRTX
    #define USES_P036   // FrameOLED
    #define USES_P037   // MQTTImport
    #define USES_P038   // NeoPixel
//    #define USES_P039   // Environment - Thermocouple

    #define USES_P040   // RFID - ID12LA/RDM6300
    // FIXME TD-er: Disabled NeoClock and Candle plugin to make builds fit in max bin size.
//    #define USES_P041   // NeoClock
//    #define USES_P042   // Candle
    #define USES_P043   // ClkOutput
//    #define USES_P044   // P1WifiGateway

    #define USES_P049   // MHZ19

//    #define USES_P052   // SenseAir
      #define USES_P053   // PMS
//    #define USES_P056   // SDS011-Dust
    #define USES_P059   // Encoder

    #define USES_P063   // TTP229_KeyPad
    #define USES_P073   // 7DG
//    #define USES_P079   // Wemos Motoshield
    #define USES_P168   // Radio FM
#endif

[TD-er]

So BUILD_NO_DEBUG is not defined? What version of the code do you have? These debug logs for the parsing of and and or have been added about a week ago.

[mackowiakp]

mega-20191108

[TD-er]

The Custom-sample.h file has BUILD_NO_DEBUG defined. Maybe you can place that in comment in your own Custom.h file?

[mackowiakp]

I dont use own Custom.h file. Just use everything "as is" from release. Except changes in define_plugin_sets.h.

[mackowiakp]

I conducted several tests with today's SW release (mega-20191113). It looks even stranger. And so the line: if %systime% > 11:50 or %systime% < 11:50 and [VAR#9]=1 and [VAR#10]=0 and %sysyear% > 2000 cause the display dim at 12:00 (??!!) So I try another time: if %systime% > 12:50 or %systime% < 11:50 and [VAR#9]=1 and [VAR#10]=0 and %sysyear% > 2000 cause the display dim at 13:00 (??!!) But if %systime% > 16:00 or %systime% < 11:50 and [VAR#9]=1 and [VAR#10]=0 and %sysyear% > 2000 cause the display dim at 17:00 as formerly.

Does not matter %systime% variable name is use or %systm_hm%

BTW. Does anybody reproduce this issue?

[uzi18]

what you have in debug logs?

[mackowiakp]

Nothing special. Just the same as You can see in listing I posted erlier. That is somthing like this:

46501652: ACT : event,LCD_DIM
46501658: Command: event
46501659: EVENT: LCD_DIM

It looks like < comparison works OK, but > not. Of course if time is comparing. Integers and floats are compared OK.

[TD-er]

if %systime% > 11:50 or %systime% < 11:50 and [VAR#9]=1 and [VAR#10]=0 and %sysyear% > 2000 cause the display dim at 12:00 (??!!)

Well you can't blame the software for being right ;) %systime% > 11:50 or %systime% < 11:50 is only false for exactly 11:50:00. Which reminds me, if the time is not expressed in seconds, we should use a range of 60 seconds for the compare.

%systime% > 12:50 or %systime% < 11:50 cause the display dim at 13:00 (??!!)

Is also correct.

%systime% > 16:00 or %systime% < 11:50 cause the display dim at 17:00

Is also correct.

When is the event LCD_DIM given? If that event is only given every now and then, it doesn't have to be right at the times you set in your rules.

[mackowiakp]

First of all, I have to apologize for the obvious errors in the test report. The tests were carried out correctly, only I thoughtlessly made copy/paste, without checking what was actually copied. So in general, the syntax has always been of the type:

%systime% > HH1:MM1 or %systime% < HH2:MM2

The difference between HH1: MM1 and HH2: MM2 was always slightly greater than 1 hour. This is because the suspicion that the issue has something to do with DST. I tried both possible variables. That is, %systime% and %systm_hm%. The effect was always the same. To be 100% sure, I will test again today. It will take a few hours but I'll make copy/paste to the file each time after each change and then I will create report. Of course, I will test both variables, i.e. %systime% and %systm_hm%. and for %systime% I will use the syntax HH:MM:SS. Once again, sorry for the obvious errors in the report.

[mackowiakp]

When is the event LCD_DIM given? If that event is only given every now and then, it doesn't have to be right at the times you set in your rules.

What I presented in the example is dimming the LCD display every day at 20:00 to 6:00. But this is only one example and the least important. I use a similar syntax in many other cases. E.g. According to the energy tariff, I have 40% cheaper electricity from 13:00 to 15:00 and from 22:00 to 6:00. In the basement I have an air dryer that draws a very large amount of electricity. Its activation/deactivation is controlled from Domoticz. But the following cases are possible in which Domoticz will not turn on/off the dryer.

• ESP reloads itself. It is true that now this effect practically does not occur, but before it was very common. Well, but there can always be "Back to the future":
• temporary power outage causing reboot of ESP:
• any network problems, including WiFi:
• any problems with RPi where Domoticz is installed or with Domoticz itself:
• unpredictable activity of my grandson (very common):

And for the above reasons, I have a rule in ESP that turns on the dryer at 13:01 or 22:01 and turns off at 15:01 or 6:01. Even without Domoticz activity and/or network problems. Of course, ESP wait in such case, until NTP is sync and than decided is a time in range to turn on/off dryer or not. Just "Plug & Pray". But even here I secured myself, because the NTP server is a Linux based SAT receiver. The receiver sync time with the HotBird satellite. So even a failure of the Internet will not prevent time synchronization in ESP. All this according to the principle: "Guarded, even Nationale-Nederlanden will insure"

[TD-er]

The rule in your first post does trigger on the event LCD_DIM, but when is that event triggered? So when is the check with the if statement performed? Also wouldn't it make more sense to have a timer set to turn something on and when to turn off? Or is it an event triggered by a sensor?

[mackowiakp]

Short question - a slightly longer answer.

The rule in your first post does trigger on the event LCD_DIM, but when is that event triggered? So when is the check with the if statement performed?

In short - in very many circumstances

Also wouldn't it make more sense to have a timer set to turn something on and when to turn off? Or is it an event triggered by a sensor?

The shortest - depending on the time, timer, sensor or order from Domoticz.

Now a longer explanation. The photo is one of my devices in which I use this type of rules (but in others too).

By default, it displays time, day name, date temperature from North and South of my house, pressure and VOC. This last indication is incorrect because the sensor is broken. This display has 4 pages with measurements collected from different ESP and RPi. These measurements are obtained by querying the Domoticz or InfluxDB database and placed in Dummy sensors. Values in Dummy sensors are updated every 30 sec but displayed only when chosen is particular page. The proximity sensor visible above, works like a switch, causing pages to switch. But "Longpress" turns on/off the FM radio that is inside (I2C controlled tuner FM module + D-class stereo amp).

Now - when the LCD_DIM procedure is called. Well, every minute is checked whether the current time is the period in which the display should be dim or light. This is in the event of a power outage or the device self reboot. That is what depending on the time. Holding your hand close to the proximity sensor will switch the pages of the display. But if the display is dim, then the first proximity of hand turns on the display backlight. If there are no more hands over the proximity sensor, the timer causes the display to return to displaying the default page after 30 sec. And if it's just the dim period, it turns off the backlight. If an emergency situation has occurred (for example, the entrance gate has jammed due to snowfall), the display blinks, while displaying the corresponding message in large letters. So dim on/off due to the sensor (although not connected directly to the device). If I activate the home alarm arming Domoticz sends an order to the device to dim the display. I have a few another ideas what this device should do because it was expensive. That is to say, the expensive housing was made as a 3D printout in high resolution.

And now the test results from today: if %systime% > 6:20:00 or %systime% < 6:00:00 and [VAR#9]=1 and [VAR#10]=0 and %sysyear% > 2000 Dim at 7:00

if %systm_hm% > 7:20 or %systm_hm% < 6:00 and [VAR#9]=1 and [VAR#10]=0 and %sysyear% > 2000 Dim at 8:00

if %systm_hm% > 9:00 or %systm_hm% < 6:00 and [VAR#9]=1 and [VAR#10]=0 and %sysyear% > 2000 Dim at 10:00

if %systime% > 11:00:00 or %systime% < 6:00:00 and [VAR#9]=1 and [VAR#10]=0 and %sysyear% > 2000 Dim at 12:00

[TD-er]

Hmm just as if it is only checking the first number of the time and nothing behind it.

[mackowiakp]

As a workaround, will change %systime% or %systm_hm% to %syssec_d%. So integers will be compared. At least the time`s are set once, not everyday. And calculation of number of second from beginning of the day is simple. But less "human readable".

[mackowiakp]

Hmm just as if it is only checking the first number of the time and nothing behind it.

If so, that means that there is the same problem with %sunset%, %sunset-1h%, %sunrise%, and %sunrise+10m% variables. Maybe more.

[TD-er]

@mackowiakp Yep that's true. And it also means I broke the parsing of it...

[mackowiakp]

No bugs no software.....

[TD-er]

No bugs no software.....

Well, then we have a lot of software...

[mackowiakp]

Over 20 years ago, I was making controller for submersible pump (on a Z80 processor). And I was able to boil water in a well. It happens...

[TD-er]

My first computer had a Z80A... when I was 7 years old :) (Toshiba HX10, MSX computer)

[mackowiakp]

Well, memories..... I started my computer education on Soviet copy of IBM Mainframe (64 bits!) in 1980. Then was Polish copy of PDP11 (16 bits with real UNIX !) and Commodore 64 (8 bit) as my own. And remembering the capabilities of IBM Mainframe to this day, I still can not understand how the World could have allowed the existence of hierarchical operating systems. Where root/superuser/supervisor/administrator can do everything. Horror....

[TD-er]

I added some logging to my timeStringToSeconds function with this result:

82938 : Info  : timeStringToSeconds: 11:25 -> 11:0:0
82939 : Info  : timeStringToSeconds: 20:28 -> 20:0:0

So there's the error :)

[mackowiakp]

Congrats !. As one politician said: "We stood over the abyss but we took a big step forward."

[TD-er]

It was a single 1-off error, I tried to find an extra colon starting from the place where there was one.

Results now:

103857 : Info  : timeStringToSeconds: 11:49 -> 11:49:0
103857 : Info  : timeStringToSeconds: 20:28:01 -> 20:28:1

[mackowiakp]

So problem resolved. Pretty nice!

[uzi18]

@mackowiakp also my first own computer was C=64, coding in basic,assembler etc. it was so fun :)