adding 1 year to the date - bug?
Hello, just simple test: (Date year: 2019 month: 2 day: 26) + 1 year. returns: 26 February 2020 OK (Date year: 2020 month: 2 day: 26) + 1 year. returns: 25 February 2021 What? (maybe I do not understand something about dates again) Thanks! pf
In Pharo 1 year is a duration of 365 days so it does not reflect leap years. -- Pavel 2018-02-26 10:43 GMT+01:00 Petr Fischer <petr.fischer@me.com>:
Hello, just simple test:
(Date year: 2019 month: 2 day: 26) + 1 year. returns: 26 February 2020 OK
(Date year: 2020 month: 2 day: 26) + 1 year. returns: 25 February 2021 What?
(maybe I do not understand something about dates again)
Thanks! pf
Am 26.02.2018 um 10:43 schrieb Petr Fischer <petr.fischer@me.com>:
Hello, just simple test:
(Date year: 2019 month: 2 day: 26) + 1 year. returns: 26 February 2020 OK
(Date year: 2020 month: 2 day: 26) + 1 year. returns: 25 February 2021 What?
(maybe I do not understand something about dates again)
That is a conceptual problem. 1 year is a duration. As it does not know which year it is the normal 365 days. And 2020 is a leap year so has 366 days. Thatâs why the date is shifted. Norbert
Forgot to say that this is something you can experience quite often. To me the problem is that 1 year gives a duration immediately. It should work as all units that 1 year is a unit of magnitude 1 and unit year. If you apply this to a date you could make it properly to give the date one year later. I noticed that problem when I started to use the Units package of Marcus. It works for all units except durations because these are already taken. So for me there would be two benefits changing that. Norbert
Am 26.02.2018 um 10:48 schrieb Norbert Hartl <norbert@hartl.name>:
Am 26.02.2018 um 10:43 schrieb Petr Fischer <petr.fischer@me.com>:
Hello, just simple test:
(Date year: 2019 month: 2 day: 26) + 1 year. returns: 26 February 2020 OK
(Date year: 2020 month: 2 day: 26) + 1 year. returns: 25 February 2021 What?
(maybe I do not understand something about dates again)
That is a conceptual problem. 1 year is a duration. As it does not know which year it is the normal 365 days. And 2020 is a leap year so has 366 days. Thatâs why the date is shifted.
Norbert
+1 Doru
On Feb 26, 2018, at 10:54 AM, Norbert Hartl <norbert@hartl.name> wrote:
Forgot to say that this is something you can experience quite often. To me the problem is that 1 year gives a duration immediately. It should work as all units that 1 year is a unit of magnitude 1 and unit year. If you apply this to a date you could make it properly to give the date one year later. I noticed that problem when I started to use the Units package of Marcus. It works for all units except durations because these are already taken. So for me there would be two benefits changing that.
Norbert
Am 26.02.2018 um 10:48 schrieb Norbert Hartl <norbert@hartl.name>:
Am 26.02.2018 um 10:43 schrieb Petr Fischer <petr.fischer@me.com>:
Hello, just simple test:
(Date year: 2019 month: 2 day: 26) + 1 year. returns: 26 February 2020 OK
(Date year: 2020 month: 2 day: 26) + 1 year. returns: 25 February 2021 What?
(maybe I do not understand something about dates again)
That is a conceptual problem. 1 year is a duration. As it does not know which year it is the normal 365 days. And 2020 is a leap year so has 366 days. Thatâs why the date is shifted.
Norbert
-- www.tudorgirba.com www.feenk.com "What we can governs what we wish."
NorbertHartl wrote
Forgot to say that this is something you can experience quite often. To me the problem is that 1 year gives a duration immediately. It should work as all units that 1 year is a unit of magnitude 1 and unit year. If you apply this to a date you could make it properly to give the date one year later.
Yes!!! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
So "date addMonths: 12" behaves better for my needs. Thanks
Hello, just simple test:
(Date year: 2019 month: 2 day: 26) + 1 year. returns: 26 February 2020 OK
(Date year: 2020 month: 2 day: 26) + 1 year. returns: 25 February 2021 What?
(maybe I do not understand something about dates again)
Thanks! pf
Am 26.02.18 um 11:13 schrieb Petr Fischer:
So "date addMonths: 12" behaves better for my needs. Thanks Hmm. We've had this discussion just the other day at Lunch. What is a month? Should addMonths: 1 and then subtractMonths: 1 on January 31st bring you back to January 31st? How would you implement that?
I guess this is a problem that cannot be solved by a machine without additional context. Does 1 month later mean "on this day next month" or does it mean "exactly as many days in the future as the current month has days"? None of the two? Can one month later be in March when today is January 30th? It seems years and months are a bit incompatible with informatics ;-) In my opinion, there is more info needed than "x months/years later" in order to calculate the correct result. Joachim
Hello, just simple test:
(Date year: 2019 month: 2 day: 26) + 1 year. returns: 26 February 2020 OK
(Date year: 2020 month: 2 day: 26) + 1 year. returns: 25 February 2021 What?
(maybe I do not understand something about dates again)
Thanks! pf
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1Â Â Â Â Â Â Â Â Â Â Â Â Â http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0Â Â Â Â Â Fax: +49 7141 56 10 86 1
This is a discussion we already had years ago. And comes back every once in a while. Pharo, and all dialects to my knowledge, uses incremental based calculations instead of field based calculations (like java.util.Calendar). This is the best thread I remember where we discussed this. http://forum.world.st/Interesting-Date-Time-Thread- on-Squeak-Dev-td4778652.html#a4778970 Regards, -- Esteban. El feb. 26, 2018 7:33 AM, "jtuchel@objektfabrik.de" <jtuchel@objektfabrik.de> escribió: Am 26.02.18 um 11:13 schrieb Petr Fischer: So "date addMonths: 12" behaves better for my needs. Thanks
Hmm. We've had this discussion just the other day at Lunch. What is a month? Should addMonths: 1 and then subtractMonths: 1 on January 31st bring you back to January 31st? How would you implement that? I guess this is a problem that cannot be solved by a machine without additional context. Does 1 month later mean "on this day next month" or does it mean "exactly as many days in the future as the current month has days"? None of the two? Can one month later be in March when today is January 30th? It seems years and months are a bit incompatible with informatics ;-) In my opinion, there is more info needed than "x months/years later" in order to calculate the correct result. Joachim
Hello, just simple test:
(Date year: 2019 month: 2 day: 26) + 1 year. returns: 26 February 2020 OK
(Date year: 2020 month: 2 day: 26) + 1 year. returns: 25 February 2021 What?
(maybe I do not understand something about dates again)
Thanks! pf
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
Thanks for discussion thread link. And yes, I need to implement it myself for customer needs, especially things like: January 31 + 1 month = February 28/29 February 29 + 1 year = February 28 etc. :) pf
This is a discussion we already had years ago. And comes back every once in a while.
Pharo, and all dialects to my knowledge, uses incremental based calculations instead of field based calculations (like java.util.Calendar).
This is the best thread I remember where we discussed this. http://forum.world.st/Interesting-Date-Time-Thread- on-Squeak-Dev-td4778652.html#a4778970
Regards,
-- Esteban.
El feb. 26, 2018 7:33 AM, "jtuchel@objektfabrik.de" <jtuchel@objektfabrik.de> escribió:
Am 26.02.18 um 11:13 schrieb Petr Fischer:
So "date addMonths: 12" behaves better for my needs. Thanks
Hmm. We've had this discussion just the other day at Lunch. What is a month? Should addMonths: 1 and then subtractMonths: 1 on January 31st bring you back to January 31st? How would you implement that?
I guess this is a problem that cannot be solved by a machine without additional context. Does 1 month later mean "on this day next month" or does it mean "exactly as many days in the future as the current month has days"? None of the two? Can one month later be in March when today is January 30th?
It seems years and months are a bit incompatible with informatics ;-) In my opinion, there is more info needed than "x months/years later" in order to calculate the correct result.
Joachim
Hello, just simple test:
(Date year: 2019 month: 2 day: 26) + 1 year. returns: 26 February 2020 OK
(Date year: 2020 month: 2 day: 26) + 1 year. returns: 25 February 2021 What?
(maybe I do not understand something about dates again)
Thanks! pf
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
It makes sense to add a Duration to a DateAndTime. It does not make sense to add a Duration to a Date. I can't check Pharo because I haven't managed to get it working on this laptop (x86-64 + ubuntu 17), but Squeak has Date>>addMonths: (edited for clarity): addMonths: monthCount |m year month maxDaysInMonth day| m := monthCount + self monthIndex - 1. year := m // 12 + self year. month := m \\ 12 + 1. maxDaysInMonth := Month daysInMonth: month forYear: year. day := self dayOfMonth min: maxDaysInMonth. ^ Date newDay: day month: month year: year This may or may not do what your customer wants. On 26 February 2018 at 22:43, Petr Fischer <petr.fischer@me.com> wrote:
Hello, just simple test:
(Date year: 2019 month: 2 day: 26) + 1 year. returns: 26 February 2020 OK
(Date year: 2020 month: 2 day: 26) + 1 year. returns: 25 February 2021 What?
(maybe I do not understand something about dates again)
Thanks! pf
participants (8)
-
Esteban A. Maringolo -
jtuchel@objektfabrik.de -
Norbert Hartl -
Pavel Krivanek -
Petr Fischer -
Richard O'Keefe -
Sean P. DeNigris -
Tudor Girba