Inconsistent behaviour with a valid lease(s) in the leases' DB and no DHCP server up.

timeout 131;
retry 33;
reboot 9;
select-timeout 3;
initial-interval 2;

interface "eth1" {
  request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name, ntp-servers, vendor-encapsulated-options, dhcp-renewal-time, dhcp-rebinding-time;
  require subnet-mask;
}

The current date and time are: Wed 03 Feb 2021 12:33:20 PM PST
The lease entry is as follows:

lease {
  interface "eth1";
  fixed-address 10.1.1.92;
  option subnet-mask 255.255.255.128;
  option routers 10.1.1.1;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers ...;
  option dhcp-server-identifier ...;
  option domain-name "...";
  renew 4 2021/02/04 13:10:16;
  rebind 4 2021/02/04 13:11:16;
  expire 4 2021/02/04 13:13:16;
}
The exchange with a DHCP server (that is down at the very moment) is nothing extraordinary:
- Request
- Discover
- Discover
....
- Discover

(133 seconds passed) and stop. Of course the client starts using formerly assigned IP address of 10.1.1.92 .

When the date changes at midnight so the 4th of February starts, the client starts sending DHCP Discovers again.
First couple questions are: Is this expected behaviour? If not so, why it stopped sending Discovers ? 

I was curious and manually modified the lease  to expire not the next day but in 30 minutes:

lease {
  interface "eth1";
  fixed-address 10.1.1.92;
  option subnet-mask 255.255.255.128;
  option dhcp-lease-time 3600;
  option routers 10.1.1.1;
  option dhcp-message-type 5;
  option dhcp-server-identifier ....;
  option domain-name-servers ....
  option domain-name "....";
  renew 3 2021/02/03 13:02:23;
  rebind 3 2021/02/03 13:03:23;
  expire 3 2021/02/03 13:05:23;
}
Interestingly the client did not start with DHCP Request as if the lease would already have expired. I thought it might have been the time-zone setting playing role but this was not the case checked the system UTC time and the lease should still be valid.
The client has kept sending Discovers perpetually and accordingly to the configured protocol timings (as one would expect) of course not getting any offer (server still down).

Would the afore described behaviour be an indication of an undocumented feature (bug) ? I read in the documentation that client stopping sending discovers after a timeout would be anticipated in the case of  a valid static lease, which is not the case here.

I would hugely appreciate any insight in the described behaviour.