2-6) fixed.
1) Not a bug, though I see no need for expiration timestamps before 
1970 in this table.

Also added some sanity checking such that a user cannot configure 
expiration windows when there is no field configured.

Can we wait with changelog / release till I complete the lock / fail 
count feature today or monday?

Changes have been made in Git for this ticket:

[#10423] Horde_Auth_Sql 1.0.4 expiration feature - make resetPassword 
and addUser properly set expiration values if needed

  1 files changed, 21 insertions(+), 1 deletions(-)
http://git.horde.org/horde-git/-/commit/484c21ca61a13eb7998eea2748c28b32aafe5ceb

Changes have been made in Git for this ticket:

[#10423] Horde_Auth_Sql 1.0.4 expiration feature - repairs updateUser issues

  1 files changed, 20 insertions(+), 14 deletions(-)
http://git.horde.org/horde-git/-/commit/c7b0fd28d3363b7fb1adc0ce089a5a06cb8460a9

Wasn't aware of that. I've always only known positive timestamps.
Moreover, time gives me a positive value, but that formular involving 
time and mktime returns a negative integer. If Timestamps are a number 
of seconds since 1970, this should be before 1970 but then the formula 
is broken. I'd rather ditch the formula in favor of 
http://www.php.net/manual/en/class.datetime.php as we're PHP 5.2+ now.

Yes. Adding it makes saving work but then horde expires my user as any 
negative timestamp is before $now.

I'll do.

Not sure why that's a problem? Unix timestamps are signed 32 bit integers.
Not sure about this, but it might be due to the errors described in (4).
Appears to be a bug.
If you are talking about Horde_Auth_Sql#updateUser(), then I agree - 
this doesn't look correct. Looks like it was included within the else 
clause erroneously. Also, it appears it could be a copy/paste error, 
as the hard expiration calc is using the $date variable that was 
already incremented by soft exp.
Looks like it's missing the $query portion for hard expiration.
Sounds like a bug.
Go for it :)

Excuse me if I got something wrong and this is all bogus.

The Horde_Auth_Sql driver provides account password expiration in a 
soft (warn) and hard (lock) flavour.

To me this feature looks totally broken in Horde 4.

1) The migration file creates the soft and hard timestamp fields as 
signed int 11 rather than unsigned. (tested on mysql)

2) The calculation routine produces a negative value for the soft and 
hard expiration timestamp. This means users changing password 
immediately expired accounts if it wasn't for 5)

3) The hard expiration timestamp is calculated via soft_expiration_window.

4) The hard expiration timestamp is completely ignored if soft 
expiration is not configured - is this intended? The calculation of 
hard_expiration_date at least looks a little like this could be true - 
but see 3)

5) If hard expiration is configured, changing users is completely 
broken because the generated SQL has more values than fields (or other 
way around, the last value is treated as a key).

6) The addUser routine doesn't initialize these additional fields. As 
a result, all accounts last forever until the user changes credentials 
for the first time.

I have checked this against 1.0.4 after I had initial issues with git, 
where I checked in my own additions today.

What puzzles me is the math bit. I think it dates back to horde3 and I 
doubt it could be broken for so long without anybody noticing.

I think I can fix this as I'm working on #10387 already.

Just want somebody to verify I'm not chasing my very own installation 
troubles.