On Tue, 2013-01-22 at 15:50 +0100, Tomas Babej wrote: > Here I bring the updated version of the patch. Please note, that I > *added* a flag attribute to ipadb_ldap_attr_to_krb5_timestamp > function, that controls whether the timestamp will be checked for > overflow or not. The reasoning behind this is that some attributes > will not be set to future dates, due to their inherent nature - such > as krbLastSuccessfulAuth or krbLastAdminUnlock. > > These are all related to past dates, and it would make no sense to set > them to future dates, even manually. Therefore I'd rather represent > negative values in these attributes as past dates. They would have to > be set manually anyway, because they would represent timestamps before > the beginning of the unix epoch, however, I find this approach better > than pushing them up to year 2038 in case such things happens. > > Any objections to this approach? > I am not sure I understand what is the point of giving this option to callers. A) How does an API user know when to use one or the other option. B) What good does it make to have the same date return different results based on a flag ?
What will happen later on when MIT will 'fix' the 2038 limit by changing the meaning of negative timestamps ? Keep in mind that right now negative timestamps are not really valid in the MIT code. Unless there is a 'use' for getting negative timestamps I think it is only harmful to allow it and consumers would only be confused on whether it should be used or not. So my first impression is that you are a bit overthinking here and we should instead always force the same behavior for all callers and always check and enforce endoftime dates. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
