Interesting Date/Time Thread on Squeak Dev
From http://forum.world.st/Could-we-have-1-api-that-work-across-all-of-the-datish... : On Fri, Sep 12, 2014 at 8:54 AM, Chris Muller <[hidden email]> wrote: On Fri, Sep 12, 2014 at 10:38 AM, Chris Cunningham <[hidden email]> wrote: > Ok. > > Date today + 15 days > Date today + 1 day > ((Date today + 1 day) - Date today) days > > That works. So, does this mean that we should deprecate the following > methods in Date so that the observed API doesn't confuse future users? > #addDays:, #addMonths:, #subtractDays:, #subtractDate: ? Well, you won't be able to replicate #addMonths: with the binary operators, because how long is "1 month?" And if we have addMonths: then it follows that we would have addDays: and addYears: for consistency (I see I have addYears: added in my own personal core-extensions package). Actually, you can add 1 month and 1 year, if you want. I have proposed alterations in the InBox that does this - Kernel-cbc.870 and Collections-cbc.582 (the later of which does not include Collections-cbc.581). These collections change #+ in DateAndTime to double-dispatch to the operand, sending the method #addToDateTime:. This does the same logic on all objects the previously could be added to a DateAndTime (as tested in KernelTests-cbc.277). This allows the introduction of GenericMonth and GenericYear, so that we CAN do things like DateAndTime now + 4 months This 'GenericMonth' simple holds the number of months that you want to add (or subtract), and then does the appropriate addition of days based on the DateAndTime. It handles different sizes of months, and leap years, just fine. SImilarly for GenericYear. It does make some assumptions on what a 'month' is. 1: If you add a month, you want the result to be in the next calendar month, never the following one. 2: If you add a month, you want the same day of the month if possible, and if not (becaue the next month has less days), then the closest that you can get to it. 3: Similarly, if you subtract a month, you want it in the previous calendar month, and as close to the starting day of the month as you can get. 4: If you add more than 1 month, you want to end up in the right calendar month that you would expect, and as close to the starting day of the month as you can. 5: Similarly with years - next year, same month, same day (or as close as you can get - February is fun!); same for subtracting. So, adding 1 month to August 31 would give September 30th; adding 2 months to August 31 would give October 31st. And adding 1 month to September 30th would give October 30th. I did this because I think a desired API should be as complete and consistent as we can get it - I really didn't like having to mix the two (or more) styles: DateAndTime now + 1 day DateAndTime now addMonths: 1 -cbc ----- Cheers, Sean -- View this message in context: http://forum.world.st/Interesting-Date-Time-Thread-on-Squeak-Dev-tp4778652.h... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
From http://forum.world.st/Next-version-of-Date-DateAndTime-and-Duration-API-upda... : Now in the InBox: KernelTests-cbc.278.mcz Kernel-cbc.871.mcz The tests add in test for expected Duration addition and subtraction from each other, including the new GenericMonth and GenericYear, and the very new GenericDuration. It also adds a few more tests for LeapYear tests with adding years to them. The test are still based on what it currently does, with the exceptions listed previously (I haven't really changed any to expect failures, as has been suggested - that will come shortly. For now, I want to try to cause little to no changes o expected behavior first - just new behavior for now). Kernel adds the GenericDuration, and handles adding and subtracting GenericMonth, GenericYear, and GenericDurations togeher in a rational way. This involves turning + and - in Durations into a double-dispatch so that it will work. There are no comments yet in these classes - they will be there before the weekend is over at the latest. Any comments are more than welcome. -cbc ----- Cheers, Sean -- View this message in context: http://forum.world.st/Interesting-Date-Time-Thread-on-Squeak-Dev-tp4778652p4... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi Sean, did you see issue 13229 (https://pharo.fogbugz.com/f/cases/13229/Year-arithmetic-broken)? It adds a new class AnnualDuration to allow for correct year based arithmetics. It also introduces floats for seconds (with nano seconds as base). I guess that issue and your change will conflict but as I understand it, your change probably does pretty much the same (for the year part at least)? Could you take a look? Cheers, Max On 19.09.2014, at 13:54, Sean P. DeNigris <sean@clipperadams.com> wrote:
From http://forum.world.st/Next-version-of-Date-DateAndTime-and-Duration-API-upda... :
Now in the InBox: KernelTests-cbc.278.mcz Kernel-cbc.871.mcz The tests add in test for expected Duration addition and subtraction from each other, including the new GenericMonth and GenericYear, and the very new GenericDuration. It also adds a few more tests for LeapYear tests with adding years to them.
The test are still based on what it currently does, with the exceptions listed previously (I haven't really changed any to expect failures, as has been suggested - that will come shortly. For now, I want to try to cause little to no changes o expected behavior first - just new behavior for now).
Kernel adds the GenericDuration, and handles adding and subtracting GenericMonth, GenericYear, and GenericDurations togeher in a rational way. This involves turning + and - in Durations into a double-dispatch so that it will work.
There are no comments yet in these classes - they will be there before the weekend is over at the latest.
Any comments are more than welcome.
-cbc
----- Cheers, Sean -- View this message in context: http://forum.world.st/Interesting-Date-Time-Thread-on-Squeak-Dev-tp4778652p4... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Max Leske wrote
your change
It's not mine. I just scanned the thread from Squeak Dev and was intrigued because I've run into this limitation (the tension between year/month/etc as a conceptual ideal, and those entities as a specific number of days in context) a bunch before ----- Cheers, Sean -- View this message in context: http://forum.world.st/Interesting-Date-Time-Thread-on-Squeak-Dev-tp4778652p4... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 19.09.2014, at 14:16, Sean P. DeNigris <sean@clipperadams.com> wrote:
Max Leske wrote
your change
It's not mine. I just scanned the thread from Squeak Dev and was intrigued because I've run into this limitation (the tension between year/month/etc as a conceptual ideal, and those entities as a specific number of days in context) a bunch before
Ok. Then Iâll look at it.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Interesting-Date-Time-Thread-on-Squeak-Dev-tp4778652p4... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Oops. Didnât realize that thread was from Squeak dev. So thereâs no Pharo implementation of that change for now anyway. On 19.09.2014, at 14:35, Max Leske <maxleske@gmail.com> wrote:
On 19.09.2014, at 14:16, Sean P. DeNigris <sean@clipperadams.com> wrote:
Max Leske wrote
your change
It's not mine. I just scanned the thread from Squeak Dev and was intrigued because I've run into this limitation (the tension between year/month/etc as a conceptual ideal, and those entities as a specific number of days in context) a bunch before
Ok. Then Iâll look at it.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Interesting-Date-Time-Thread-on-Squeak-Dev-tp4778652p4... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Ok, so I read Chrisâ e-mail and Iâm intrigued. Sven, youâre still right about financial months being 30 days for instance but the thing is that the current implementation seems broken (or inconsisten at least) and doesnât honor that case either. *Not* making the change will not help us either⦠So Iâd say: letâs do it. If somebody objects (or proposes a change) then we can handle that but at least we can claim that we try to give the users what we preach, like writing natural language like code (e.g. âx + 1 monthâ which is currently not possible). Thatâs my view at least. Also: weâre changing so much stuff in Pharo anyway all the time, I donât think this would hurt. Cheers, Max On 19.09.2014, at 14:37, Max Leske <maxleske@gmail.com> wrote:
Oops. Didnât realize that thread was from Squeak dev. So thereâs no Pharo implementation of that change for now anyway.
On 19.09.2014, at 14:35, Max Leske <maxleske@gmail.com> wrote:
On 19.09.2014, at 14:16, Sean P. DeNigris <sean@clipperadams.com> wrote:
Max Leske wrote
your change
It's not mine. I just scanned the thread from Squeak Dev and was intrigued because I've run into this limitation (the tension between year/month/etc as a conceptual ideal, and those entities as a specific number of days in context) a bunch before
Ok. Then Iâll look at it.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Interesting-Date-Time-Thread-on-Squeak-Dev-tp4778652p4... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Being consistent is of course better (note however that #month does not exist today, probably because it is hard to define). The double-dispatching is also good. But I would have to study the actual code in detail to have a better opinion. On 19 Sep 2014, at 14:48, Max Leske <maxleske@gmail.com> wrote:
Ok, so I read Chrisâ e-mail and Iâm intrigued.
Sven, youâre still right about financial months being 30 days for instance but the thing is that the current implementation seems broken (or inconsisten at least) and doesnât honor that case either. *Not* making the change will not help us eitherâ¦
So Iâd say: letâs do it. If somebody objects (or proposes a change) then we can handle that but at least we can claim that we try to give the users what we preach, like writing natural language like code (e.g. âx + 1 monthâ which is currently not possible).
Thatâs my view at least. Also: weâre changing so much stuff in Pharo anyway all the time, I donât think this would hurt.
Cheers, Max
On 19.09.2014, at 14:37, Max Leske <maxleske@gmail.com> wrote:
Oops. Didnât realize that thread was from Squeak dev. So thereâs no Pharo implementation of that change for now anyway.
On 19.09.2014, at 14:35, Max Leske <maxleske@gmail.com> wrote:
On 19.09.2014, at 14:16, Sean P. DeNigris <sean@clipperadams.com> wrote:
Max Leske wrote
your change
It's not mine. I just scanned the thread from Squeak Dev and was intrigued because I've run into this limitation (the tension between year/month/etc as a conceptual ideal, and those entities as a specific number of days in context) a bunch before
Ok. Then Iâll look at it.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Interesting-Date-Time-Thread-on-Squeak-Dev-tp4778652p4... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 19/09/2014 13:48, Max Leske wrote:
Ok, so I read Chrisâ e-mail and Iâm intrigued.
Sven, youâre still right about financial months being 30 days for instance but the thing is that the current implementation seems broken (or inconsisten at least) and doesnât honor that case either. *Not* making the change will not help us eitherâ¦
So Iâd say: letâs do it. If somebody objects (or proposes a change) then we can handle that but at least we can claim that we try to give the users what we preach, like writing natural language like code (e.g. âx + 1 monthâ which is currently not possible).
Thatâs my view at least. Also: weâre changing so much stuff in Pharo anyway all the time, I donât think this would hurt.
That comment re 30 day months in financial is not totally correct. A common reason for calculating days in a financial calculation is for interest calculation and then you don't just need a number for the day difference but also for the number of days in a year. When I did this I think I had to support many ways of calculating the fraction of a year that was the difference between two dates depending on the interest basis (ie the contract terms) , Wikipedia gives 11 <http://en.wikipedia.org/wiki/Day_count_convention> So I think that adding a financial number of days into a basic date object does not make sense as it will not be correct in many cases. The best way I have seen is to pass a daycount basis strategy class into the calculation and that strategy object does the calculation. -- Mark
On 19.09.2014, at 19:14, Mark Bestley <st@bestley.co.uk> wrote:
On 19/09/2014 13:48, Max Leske wrote:
Ok, so I read Chrisâ e-mail and Iâm intrigued.
Sven, youâre still right about financial months being 30 days for instance but the thing is that the current implementation seems broken (or inconsisten at least) and doesnât honor that case either. *Not* making the change will not help us eitherâ¦
So Iâd say: letâs do it. If somebody objects (or proposes a change) then we can handle that but at least we can claim that we try to give the users what we preach, like writing natural language like code (e.g. âx + 1 monthâ which is currently not possible).
Thatâs my view at least. Also: weâre changing so much stuff in Pharo anyway all the time, I donât think this would hurt.
That comment re 30 day months in financial is not totally correct.
A common reason for calculating days in a financial calculation is for interest calculation and then you don't just need a number for the day difference but also for the number of days in a year. When I did this I think I had to support many ways of calculating the fraction of a year that was the difference between two dates depending on the interest basis (ie the contract terms) , Wikipedia gives 11 <http://en.wikipedia.org/wiki/Day_count_convention>
So I think that adding a financial number of days into a basic date object does not make sense as it will not be correct in many cases. The best way I have seen is to pass a daycount basis strategy class into the calculation and that strategy object does the calculation.
I like the idea of using strategies. Although some might argue that such a change would unnecessarily bloat the code, strategies would give us the ability to define our âstandardâ calculation in a central place while enabling everyone to use their custom calculations.
-- Mark
On 23/09/2014 08:48, Max Leske wrote:
On 19.09.2014, at 19:14, Mark Bestley <st@bestley.co.uk> wrote:
On 19/09/2014 13:48, Max Leske wrote:
Ok, so I read Chrisâ e-mail and Iâm intrigued.
Sven, youâre still right about financial months being 30 days for instance but the thing is that the current implementation seems broken (or inconsisten at least) and doesnât honor that case either. *Not* making the change will not help us eitherâ¦
So Iâd say: letâs do it. If somebody objects (or proposes a change) then we can handle that but at least we can claim that we try to give the users what we preach, like writing natural language like code (e.g. âx + 1 monthâ which is currently not possible).
Thatâs my view at least. Also: weâre changing so much stuff in Pharo anyway all the time, I donât think this would hurt.
That comment re 30 day months in financial is not totally correct.
A common reason for calculating days in a financial calculation is for interest calculation and then you don't just need a number for the day difference but also for the number of days in a year. When I did this I think I had to support many ways of calculating the fraction of a year that was the difference between two dates depending on the interest basis (ie the contract terms) , Wikipedia gives 11 <http://en.wikipedia.org/wiki/Day_count_convention>
So I think that adding a financial number of days into a basic date object does not make sense as it will not be correct in many cases. The best way I have seen is to pass a daycount basis strategy class into the calculation and that strategy object does the calculation.
I like the idea of using strategies. Although some might argue that such a change would unnecessarily bloat the code, strategies would give us the ability to define our âstandardâ calculation in a central place while enabling everyone to use their custom calculations.
It does not bloat the normal code - makes it smaller.You only need the extra code if you need the extra financial calculations which most users won't. Also it is not a unnecessary increase in code as if you neded the calculations then you need the extra complexity -- Mark
Iâve taken a quick look at the implementation. Itâs not strategy based but it would be easy enough for a user to add extensions (e.g. #fiscalYear) that have the same effect. Apart from that, I think it would make more sense to inlclude the work that is being done for Squeak (including GenericMonth etc.) instead of using a similar but incompatible solution, which only addresses the problem of year duration anyway. Thereâs also the issue with the change of the âsecondsâ variable to use floats instead on integers. Since issue 13229 isnât my issue anyway and Carlo doesnât seem to be active anymore I vote for closing the issue and for possibly adopting the Squeak implementation in the future. I will cose the issue now, if somebody objects, feel free to reopen it. Cheers, Max On 24.09.2014, at 12:42, Mark Bestley <st@bestley.co.uk> wrote:
On 23/09/2014 08:48, Max Leske wrote:
On 19.09.2014, at 19:14, Mark Bestley <st@bestley.co.uk> wrote:
On 19/09/2014 13:48, Max Leske wrote:
Ok, so I read Chrisâ e-mail and Iâm intrigued.
Sven, youâre still right about financial months being 30 days for instance but the thing is that the current implementation seems broken (or inconsisten at least) and doesnât honor that case either. *Not* making the change will not help us eitherâ¦
So Iâd say: letâs do it. If somebody objects (or proposes a change) then we can handle that but at least we can claim that we try to give the users what we preach, like writing natural language like code (e.g. âx + 1 monthâ which is currently not possible).
Thatâs my view at least. Also: weâre changing so much stuff in Pharo anyway all the time, I donât think this would hurt.
That comment re 30 day months in financial is not totally correct.
A common reason for calculating days in a financial calculation is for interest calculation and then you don't just need a number for the day difference but also for the number of days in a year. When I did this I think I had to support many ways of calculating the fraction of a year that was the difference between two dates depending on the interest basis (ie the contract terms) , Wikipedia gives 11 <http://en.wikipedia.org/wiki/Day_count_convention>
So I think that adding a financial number of days into a basic date object does not make sense as it will not be correct in many cases. The best way I have seen is to pass a daycount basis strategy class into the calculation and that strategy object does the calculation.
I like the idea of using strategies. Although some might argue that such a change would unnecessarily bloat the code, strategies would give us the ability to define our âstandardâ calculation in a central place while enabling everyone to use their custom calculations.
It does not bloat the normal code - makes it smaller.You only need the extra code if you need the extra financial calculations which most users won't. Also it is not a unnecessary increase in code as if you neded the calculations then you need the extra complexity
-- Mark
Part of that is in https://pharo.fogbugz.com/f/cases/13229/Year-arithmetic-broken Furthermore, I am not so sure all this is a good idea, year/month durations are not constants and are dealt with differently in many context (say the financial world). January 30 + 1 month ? January 31 + 1 month ? Februari 29 2004 + 1 year ? And given all sorts of cleverness, will basic math rules still work ? A +B = B + A A + B = C => C - B = A On 19 Sep 2014, at 13:54, Sean P. DeNigris <sean@clipperadams.com> wrote:
From http://forum.world.st/Next-version-of-Date-DateAndTime-and-Duration-API-upda... :
Now in the InBox: KernelTests-cbc.278.mcz Kernel-cbc.871.mcz The tests add in test for expected Duration addition and subtraction from each other, including the new GenericMonth and GenericYear, and the very new GenericDuration. It also adds a few more tests for LeapYear tests with adding years to them.
The test are still based on what it currently does, with the exceptions listed previously (I haven't really changed any to expect failures, as has been suggested - that will come shortly. For now, I want to try to cause little to no changes o expected behavior first - just new behavior for now).
Kernel adds the GenericDuration, and handles adding and subtracting GenericMonth, GenericYear, and GenericDurations togeher in a rational way. This involves turning + and - in Durations into a double-dispatch so that it will work.
There are no comments yet in these classes - they will be there before the weekend is over at the latest.
Any comments are more than welcome.
-cbc
----- Cheers, Sean -- View this message in context: http://forum.world.st/Interesting-Date-Time-Thread-on-Squeak-Dev-tp4778652p4... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 19.09.2014, at 14:16, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Part of that is in https://pharo.fogbugz.com/f/cases/13229/Year-arithmetic-broken
Furthermore, I am not so sure all this is a good idea, year/month durations are not constants and are dealt with differently in many context (say the financial world).
January 30 + 1 month ? January 31 + 1 month ?
Issue 13299 doesnât change that (I donât know about the other change). There is still only the Month object which knows its number of days, so a month will always be used in a defined context.
Februari 29 2004 + 1 year ?
This one is hard and the change in issue 13299 does indeed make the assumption that February 29 2004 + 1 year = February 28 2005. One might argue that is should be March 1. But: that is also the assumption the *current* implementation makes, so no change there.
And given all sorts of cleverness, will basic math rules still work ?
A +B = B + A A + B = C => C - B = A
On 19 Sep 2014, at 13:54, Sean P. DeNigris <sean@clipperadams.com> wrote:
From http://forum.world.st/Next-version-of-Date-DateAndTime-and-Duration-API-upda... :
Now in the InBox: KernelTests-cbc.278.mcz Kernel-cbc.871.mcz The tests add in test for expected Duration addition and subtraction from each other, including the new GenericMonth and GenericYear, and the very new GenericDuration. It also adds a few more tests for LeapYear tests with adding years to them.
The test are still based on what it currently does, with the exceptions listed previously (I haven't really changed any to expect failures, as has been suggested - that will come shortly. For now, I want to try to cause little to no changes o expected behavior first - just new behavior for now).
Kernel adds the GenericDuration, and handles adding and subtracting GenericMonth, GenericYear, and GenericDurations togeher in a rational way. This involves turning + and - in Durations into a double-dispatch so that it will work.
There are no comments yet in these classes - they will be there before the weekend is over at the latest.
Any comments are more than welcome.
-cbc
----- Cheers, Sean -- View this message in context: http://forum.world.st/Interesting-Date-Time-Thread-on-Squeak-Dev-tp4778652p4... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2014-09-19 9:16 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
Part of that is in https://pharo.fogbugz.com/f/cases/13229/Year-arithmetic-broken
Furthermore, I am not so sure all this is a good idea, year/month durations are not constants and are dealt with differently in many context (say the financial world).
+1
January 30 + 1 month ? January 31 + 1 month ? Februari 29 2004 + 1 year ?
And given all sorts of cleverness, will basic math rules still work ?
A +B = B + A A + B = C => C - B = A
Pharo Date/DateAndTime are incremental[1], then all this week/month/year operations will simply add/subtract the increment from epoch. The only way to do this in a deterministic way is to have a field based Date. Regards! Esteban A. Maringolo [1] http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e310
Le 19 sept. 2014 à 14:59, Esteban A. Maringolo a écrit :
Pharo Date/DateAndTime are incremental[1], then all this week/month/year operations will simply add/subtract the increment from epoch.
The only way to do this in a deterministic way is to have a field based Date.
Yes, it would be a good idea. Then, you may have today + 1 month, today + 1 financialMonth, ...
On 19 Sep 2014, at 14:59, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2014-09-19 9:16 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
Part of that is in https://pharo.fogbugz.com/f/cases/13229/Year-arithmetic-broken
Furthermore, I am not so sure all this is a good idea, year/month durations are not constants and are dealt with differently in many context (say the financial world).
+1
January 30 + 1 month ? January 31 + 1 month ? Februari 29 2004 + 1 year ?
And given all sorts of cleverness, will basic math rules still work ?
A +B = B + A A + B = C => C - B = A
Pharo Date/DateAndTime are incremental[1], then all this week/month/year operations will simply add/subtract the increment from epoch.
The only way to do this in a deterministic way is to have a field based Date.
Saying that it is not deterministic is a bit harsh ;-)
Regards!
Esteban A. Maringolo
[1] http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e310
Very interesting link, really useful - Thx.
2014-09-19 11:14 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 19 Sep 2014, at 14:59, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2014-09-19 9:16 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>: Pharo Date/DateAndTime are incremental[1], then all this week/month/year operations will simply add/subtract the increment from epoch.
The only way to do this in a deterministic way is to have a field based Date.
Saying that it is not deterministic is a bit harsh ;-)
Sorry, it wasn't my intention. Maybe "consistent" was the proper word. :)
[1] http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e310
Very interesting link, really useful - Thx.
At least it makes you understand some pros/cons about date implementations. After reading that I understood why Java's Calendar object is field based. Additionally I would like this: '2014/08/31 24:00' asDateAndTime -> "2014/09/01 00:00" Or even better: '2014/08/31 24:00' asDateAndTime -> "2014/08/31 24:00" And: '2014/08/31 24:00' asDateAndTime = '2014/09/01 00:00' asDateAndTime Regards! Esteban A. Maringolo
On 19 Sep 2014, at 16:31, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2014-09-19 11:14 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 19 Sep 2014, at 14:59, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2014-09-19 9:16 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>: Pharo Date/DateAndTime are incremental[1], then all this week/month/year operations will simply add/subtract the increment from epoch.
The only way to do this in a deterministic way is to have a field based Date.
Saying that it is not deterministic is a bit harsh ;-)
Sorry, it wasn't my intention. Maybe "consistent" was the proper word. :)
[1] http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e310
Very interesting link, really useful - Thx.
At least it makes you understand some pros/cons about date implementations. After reading that I understood why Java's Calendar object is field based.
Additionally I would like this: '2014/08/31 24:00' asDateAndTime -> "2014/09/01 00:00"
Or even better: '2014/08/31 24:00' asDateAndTime -> "2014/08/31 24:00" And: '2014/08/31 24:00' asDateAndTime = '2014/09/01 00:00' asDateAndTime
Actually, ZTimestamp fromString: '2014/08/31 24:00:00'. => '2014-09-01T00:00:00Z' (ZTimestampFormat fromString: '2001/02/03 16:05') parse: '2014/08/31 24:00'. => '2014-09-01T00:00:00Z' but that is not really by design, it just does normalisation. I am not sure what to think of that, it is certainly interesting ;-)
2014-09-19 11:41 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
[1] http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e310
Very interesting link, really useful - Thx.
At least it makes you understand some pros/cons about date implementations. After reading that I understood why Java's Calendar object is field based.
Additionally I would like this: '2014/08/31 24:00' asDateAndTime -> "2014/09/01 00:00"
Actually, ZTimestamp fromString: '2014/08/31 24:00:00'. => '2014-09-01T00:00:00Z'
but that is not really by design, it just does normalisation.
I am not sure what to think of that, it is certainly interesting ;-)
Yes! I forgot to mention, but I did this test with ZTimestamp before and it gave me the "expected" results. I played with having ZTimestamp as the default object class for PostgresSQL's "timestamp without time zone" data type, but then I discarded this option. PostgreSQL also converts '2014-08-31 24:00' to '2014-09-01 00:00'. Regards! Esteban A. Maringolo
From http://forum.world.st/Latest-duration-API-ready-td4779363.html :
These 3 packages should be loaded (or, more likely, merged) into current Trunk for testing. They all reside in the Inbox currently
Kernel-cbc.872.mcz Collections-cbc.582.mcz KernelTests-cbc.278.mcz
They should have no collision with the current packages in Trunk. They shouldn't cause any problems with any code currently relying on how DateAndTime and Timespan classes interact with Duration classes.
And they don't currently make any changes on the assumptions as to how adding strings, time, DateAndTimes, Timespans, and Numbers to DateAndTime and Timespan works today. I'd like to make changing those assumptions a difference activity than adding in the ability to add months and years to dates.
This latest change adds #hash and comments to the GenericDurations. It also simplifies how GenericDuration works.
Thanks, -cbc
----- Cheers, Sean -- View this message in context: http://forum.world.st/Interesting-Date-Time-Thread-on-Squeak-Dev-tp4778652p4... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (6)
-
Christophe Demarey -
Esteban A. Maringolo -
Mark Bestley -
Max Leske -
Sean P. DeNigris -
Sven Van Caekenberghe