Hi I was reading the code of Date and I was expecting to get some methods such as monthNames dayNames daysInMonths Ok they are stored in ChronologyConstants but they are not accessible. There is no monthNames nor Do I imply something strange or silly? I think that it would make sense to add them. Stef
https://pharo.fogbugz.com/f/cases/17098/Improve-Date-class-API Le 24/11/15 15:59, stepharo a écrit :
Hi
I was reading the code of Date and I was expecting to get some methods such as monthNames dayNames daysInMonths
Ok they are stored in ChronologyConstants but they are not accessible. There is no monthNames nor
Do I imply something strange or silly? I think that it would make sense to add them.
Stef
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?
On Nov 24, 2015, at 3:59 PM, stepharo <stepharo@free.fr> wrote:
Hi
I was reading the code of Date and I was expecting to get some methods such as monthNames dayNames daysInMonths
Ok they are stored in ChronologyConstants but they are not accessible. There is no monthNames nor
Do I imply something strange or silly? I think that it would make sense to add them.
Stef
2015-11-24 12:14 GMT-03:00 Skip Lentz <skip.lentz@inria.fr>:
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!
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 <skip.lentz@inria.fr>:
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!
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). Esteban
On 24 Nov 2015, at 18:34, stepharo <stepharo@free.fr> 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 <skip.lentz@inria.fr>:
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!
I agree with Esteban on Chalten. Chalten currently loads on Pharo 4 and 5 without any issue. It has a lots of tests cases that help a lot to learn about it. On Thu, Nov 26, 2015 at 8:55 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
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).
Esteban
On 24 Nov 2015, at 18:34, stepharo <stepharo@free.fr> 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 <skip.lentz@inria.fr>:
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!
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 <stepharo@free.fr> 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 <skip.lentz@inria.fr>:
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!
2015-11-24 11:59 GMT-03:00 stepharo <stepharo@free.fr>:
Hi
I was reading the code of Date and I was expecting to get some methods such as monthNames dayNames daysInMonths
Ok they are stored in ChronologyConstants but they are not accessible. There is no monthNames nor
Do I imply something strange or silly? I think that it would make sense to add them.
It makes sense, maybe the class Date is not the best for those methods, but there isn't a "Calendar" like class either. Whatever is chosen, it should collaborate with the Locale, but be able to use any other locale to retrieve the names. Esteban A. Maringolo
Yes, I badly need to get it localised I added class accessors to ChronologyConstants to modify month and day names. Hilaire Le 24/11/2015 15:59, stepharo a écrit :
Hi
I was reading the code of Date and I was expecting to get some methods such as monthNames dayNames daysInMonths
Ok they are stored in ChronologyConstants but they are not accessible. There is no monthNames nor
Do I imply something strange or silly? I think that it would make sense to add them.
Stef
-- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu
Yes, I badly need to get it localised I added class accessors to ChronologyConstants to modify month and day names.
but this is dangerous because you do not know the assumption that the system is doing. I would go more in improving chalten
Hilaire
Le 24/11/2015 15:59, stepharo a écrit :
Hi
I was reading the code of Date and I was expecting to get some methods such as monthNames dayNames daysInMonths
Ok they are stored in ChronologyConstants but they are not accessible. There is no monthNames nor
Do I imply something strange or silly? I think that it would make sense to add them.
Stef
participants (6)
-
Esteban A. Maringolo -
Esteban Lorenzano -
Francisco Ortiz Peñaloza -
Hilaire -
Skip Lentz -
stepharo