I don’t know chronos, but Chalten (the Aconcagua date API) is quite nice
(overuse of globals, IMO, but you gain a lot of expressivity).
yes it was with it in mind that I wrote the mail.
So I would imrpove the date printer and key our kernel small
STef
Esteban
On 24 Nov 2015, at 18:34, stepharo <[email protected]> wrote:
Hi guys
I made the mistake to think that it was a good move to improve and make the
core more full (and complex in the past).
Now what I would love is the following.
- keep and reduce if necessary the core date classes (only used internally
by the system)
- have nice packages that we can load to represent time / calendar
-- chronos
-- aconcagua
-- or a new one
That do it the right way: with locale and so on.
Why? because it can be complex and verbose and we want to have a small core
(for many different reasons).
About the durationFormatter I think that we should definitively have more
strategies to represent dates and other
within a nice date/calendar package.
I would love that someone propose something to get the nice extensible
Calendar/Date package
Stef
Le 24/11/15 16:25, Esteban A. Maringolo a écrit :
2015-11-24 12:14 GMT-03:00 Skip Lentz <[email protected]>:
Hi,
I also had an idea for a method which returns the most significant unit of a
Duration.
For example, you have a duration of 432 days, 3 hours, 21 minutes, 5 seconds,
etc., and
it would return you "432 days" (or just “1 year”). I encountered this when
wanting to create
a time indication on e.g. a commit or a comment. It’s much more readable and
user-friendly
than a timestamp.
Would this be a nice addition to the Duration API?
It would be nice to have. But why not something like a
DurationFormatter? that in turn collaborates with the Locale to ge the
words for "Year, Month, Week" in the current language.
Regards!
