Interesting Date/Time Thread on Squeak Dev

From http://forum.world.st/Could-we-have-1-api-that-work-across-all-of-the-datish-classes-td4777676.html :

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

From http://forum.world.st/Next-version-of-Date-DateAndTime-and-Duration-API-updates-td4778871.html :

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

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 <[hidden email]> 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 ?
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 <[hidden email]> 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

On 19.09.2014, at 14:16, Sven Van Caekenberghe <[hidden email]> 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.

On 19.09.2014, at 14:16, Sean P. DeNigris <[hidden email]> 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.

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 <[hidden email]> 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 <[hidden email]> wrote:

2014-09-19 9:16 GMT-03:00 Sven Van Caekenberghe <[hidden email]>:
> 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

On 19 Sep 2014, at 14:59, Esteban A. Maringolo <[hidden email]> wrote:

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.

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 <[hidden email]> wrote:

2014-09-19 11:14 GMT-03:00 Sven Van Caekenberghe <[hidden email]>:
>
> On 19 Sep 2014, at 14:59, Esteban A. Maringolo <[hidden email]> wrote:
>
>> 2014-09-19 9:16 GMT-03:00 Sven Van Caekenberghe <[hidden email]>:
>> 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 <[hidden email]> wrote:

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 <[hidden email]>:
>>>> [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

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

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

On 19.09.2014, at 19:14, Mark Bestley <[hidden email]> wrote:

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:
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