Good Design is Imperfect Design, Part 1: Honest Names

Re:Good Design is Imperfect Design, Part 1: Honest Names by chomp on Wednesday August 04, 2021 @02:26PM (#28064449)

You expected 2021-03-31 + 1 month + 1 month to be different from 2021-03-31 + (1 month + 1 month)? I find this behavior understandable, but not apparent at first glance.

Also, FYI, this is not how GNU date works:

  $ date -d "Jan 28 next month" 
  Sun Feb 28 00:00:00 CST 2021
  $ date -d "Jan 29 next month" 
  Mon Mar 1 00:00:00 CST 2021

I could see confusion from this, depending on what libraries you are used to.

[ Parent | on HN ]

Re:Good Design is Imperfect Design, Part 1: Honest Names by mjevans on Wednesday August 04, 2021 @02:42PM (#28064614)

The inconsistency with GNU date is more visible from Feb:

  $ date -d "jan 31 next month"
  Wed Mar  3 00:00:00 PST 2021
  $ date -d "jan 30 next month"
  Tue Mar  2 00:00:00 PST 2021
  $ date -d "jan 1 next month"
  Mon Feb  1 00:00:00 PST 2021
  $ date -d "feb 28 next month"
  Sun Mar 28 00:00:00 PDT 2021

Edit: This was on my unconscious mind for a bit and I came up with an additional test case to confirm a suspicion I realized.

  $ date -d "2016-1-31 next month"
  Wed Mar  2 00:00:00 PST 2016
  date -d "2016-2-1 next month"
  Tue Mar  1 00:00:00 PST 2016
  date -d "2016-2-1 next year"
  Wed Feb  1 00:00:00 PST 2017
  $ date -d "2016-3-1 next year"
  Wed Mar  1 00:00:00 PST 2017

GNU date will add the duration of the CURRENT interval (ignoring already occurred deviations, like leap years) relative to the specified base date.

The oddity in behavior I observed above is adding the length of the month of Jan to dates in Jan. I suspect only a programmer would find that inference remotely correct.

[ Parent | on HN ]

Re:Good Design is Imperfect Design, Part 1: Honest Names by chomp on Wednesday August 04, 2021 @05:10PM (#28066361)

I suspected this when I was playing with it, but good to have the confirmation. Thanks!

[ Parent | on HN ]