With a logbook defined by 

 [test]
 Theme = default
 Comment = Test of auto-increment
 Attributes = Batch
 Subst Batch = %Y%m%d-##

the auto-incrementing of the Batch attribute within dates works when the logbook contains only entries for
today's date but otherwise will give a batch number of "01" for each entry.  

Changing line 8714 of elogd.c as follows, from:

      /* if date part changed, start over with index */
      if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) != 0)
         old_index = 0;   
      else
         /* retrieve old index */
      if (atoi(attrib[index] + loc) > old_index)
         old_index = atoi(attrib[index] + loc);
to
      /* if date part changed, start over with index */
      if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) != 0)
         break;            /* <------------- */
      else
         /* retrieve old index */
      if (atoi(attrib[index] + loc) > old_index)
         old_index = atoi(attrib[index] + loc);

appears to fix this bug when I test it.  This code is inside a loop stepping back through all log entries, and
the variable old_index is already set to zero before the loop. The existing code resets old_index whenever the
prefix of the attribute string (containing a date) does not match the "current" value of that prefix as found in
retstr (set using strftime).  So, if there are any records for dates other than today then old_index is reset
and attribute values will be set with the counter = (old_index+1) = 1.  The modified version stops comparisons
once a different date is seen, but assumes that records are date ordered.  An alternative patch:

      /* if date part matches */
      if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) == 0)
          /* retrieve old index */
         if (atoi(attrib[index] + loc) > old_index)
            old_index = atoi(attrib[index] + loc);
  
does not make this assumption and also appears to work OK when I test it.