Agree with what you say, but just an extra comment about this...
>> and must be parsed externally to return a timedelta
yes, this is why time on its own is useless because you always have to
combine it back with a date to do anything with calculations.
On Saturday, October 20, 2012 10:09:36 PM UTC+1, Niphlod wrote:
>
> +1, although what IS_TIME does (e.g. 0-24 for hours, 1-12 if am-pm is
> there, 0-60 for minutes, etc) fills all possible "requirements" for a
> single input.
>
> """
>
>> and in another field I want to accept time format of form
>> ("hours:minutes" to "hours:minutes").
>>
> """
>
> What the user asked for I think is a duration, not "time":
> - totally different concept
> - needs a custom validator
> - can only be stored as a string (or an integer storing the difference
> bewteen in seconds)
> - and must be parsed externally to return a timedelta
>
> On Saturday, October 20, 2012 10:53:56 PM UTC+2, villas wrote:
>>
>> In my experience a time field is more or less useless and you may as well
>> store the time as a string. I think everyone else may feel the same,
>> which is why IS_TIME still has no format validation even after 5 years.
>>
>> If you don't want to store as a string, then if I were you, I would
>> store as datetime and just have the same default date in every datetime
>> field. It isn't difficult to discard the unwanted date.
>>
>> However, maybe others have a different view...
>>
>>
--
