[local-time-devel] exporting 'date and 'time from the local-time package

[Attila Lendvai]

>> what we need is a shared 'date and 'time symbol between all our libs.
>
> What's wrong with using the fully-qualified symbol local-time:date?


the package prefix is just noise in code heavily using these symbols,
and then everything else should be prefixed with local-time: (or it
needs to be private, local-time::time).

alternatively we would be ok with these symbols only present in
local-time, not exported, so that we can :import-from them.


>> although exporting time will conflict with cl:time, but i still think
>> that this is The Right Way(tm). rationale:
>>
>>  - cl:time is the wrong name, it should be
>> with-resource-usage-statistics or whatever el...
>>  - local-time will eventually provide date/time abstractions, at least
>> in a form of (typep foo 'time) using a type with satisfies
>
> What do time or date mean?  CL:time is perfectly normal ("time an event"),


cl:time is only normal for people who are used to it and to the unix
time command. ask a few 10 year olds who are just learning programming
what they think this symbol might mean... i'm sure they will not
mention memory allocation printed to standard output... :)

(same applies to many other things, like the 101 key keyboard layout
everybody keeps on using... why on earth should a 10 year old learn
typing on a layout that was optimized for the mechanical bars keeping
the buttons some 100 years ago? took me at most a week to get used to
a kinesis, and i wasn't 10 when i bought mine... </rant>)


> except for the other nonstandard cruft which was added (but compare the
> unix command).  As data structures, neither has a universal canonical
> form.


well, they don't need a canonical form. they just need to encode a
date or a time of day, which i will not define here because they
exists in the common knowledge of people.

i'm open for suggestions what to use instead of 'time to encode a
point in a day.

maybe 'date and 'time-of-day?


> If these names are to be exported, I think they should be given more
> specific names.


i'm starting to lean towards just intern'ing and :import-from'ing them
from local-time when our first shared dependency loads...

-- 
 attila