Very specific programming question - generating a list of years

[dandarc]

The requirement - show a list of consecutive years in descending order from Next year to 4 years ago. Example if it is run today (7/19/2022) the day I'm writing it:

2023
2022
2021
2020
2019
2018

Developer turned in solution that was "put list of years in a database table & display that table". Upside would be if requirement changes we just change the list in the table. Downside is we've got an annual task to update this configuration table.

I'm more inclined to write a query that generates the list (oracle database):

select extract(year from sysdate) + 2 - level
from dual
connect by level <= 6

What says the MMM community? I know we have a lot of programmers here.

[neo von retorch]

Need a lot more context!

For example, in a Data Warehouse, you construct a query to generate a list of dates, which you store in a table.

In a UI, you might always take the current date and use that to programmatically generate a list of options for the user.

In an API, you might pull it from a database, but in most cases, it would be programmatic. In specific cases, you might store a year or range in configuration, if the change is not tied to the calendar, but rather some business process.

[dandarc]

This is for our transactional day-to-day web application. The requirement, as stated by the customer, is based on the current date. And we're not worried about details around possibly using the system at midnight on December 31 - ain't nobody that would be using this screen is working on New Years Eve. Not a high-volume thing - 1500 total users of the system as a whole but only 10-20 would ever use this particular screen.

So to me and given how simple the task is, it is less of a performance consideration as maintainability going forward.

[GuitarStv]

The requirement - show a list of consecutive years in descending order from Next year to 4 years ago.

I'd just put the data into excel, use excel's sort function, and then send a screenshot of it.  Requirement met!  No need for programming at all.

[CodingHare]

If you keep the list in a database, some human being needs to go in and update the list around New Years.


Pseudocode for me would be

Code: [Select]

// get today's date (lots of libraries that do this)
const currentYear = getDate.year

// initialize an empty array to hold the years
const yearsInRange = []

// Iterate through the range of years, in good code you would use less 'magic numbers' and use more defined variables
for (let i = -4, i < 2; i++) {
   yearsInRange.push(currentYear + i);
}

// sort the array to have greatest first, could also be done by tweaking how the loop above was set up
const yearsToDisplay = yearsInRange.sort(function(a, b){return b - a});

// pass yearsToDisplay to whatever dropdown display

Let's say our current year is 2022.  The loop above would generate:

i	year
-4	2018
-3	2019
-2	2020
-1	2021
0	2023
1	2023

Then i = 2, which breaks the loop.  Then the sort will generate an array going from 2023 down.

Now your solution does not require a database lookup (so it is faster) and does not require a human to maintain the list in the database (so it will work no matter what day it is without intervention.)

[neo von retorch]

web application
based on the current date
not worried about details

Doesn't sound like you need a database at all. Just about any language will have a built-in date functionality, and many have date add functionality where you add n years.

Whether you use date part and then just work with numbers, or loop over a range from like +1 to -4 and use date add should come down to programmer preference/expertise and contextual awareness.

You'll probably regret not worrying about time zones at some point. I don't know how and I don't know why, but it will happen :) At least you don't have to wake up every January 1st and insert a new record into a database ;)

[MDM]

Not a high-volume thing...only 10-20 would ever use this particular screen.

So to me and given how simple the task is, it is less of a performance consideration as maintainability going forward.

That gets my vote also: automate it so no further maintenance needed, and it won't have a material impact on response time.

[the_gastropod]

Oof. A developer wanting to use the database for this doesn't inspire confidence, to be honest. For just an example, here's how simple this should be (this is using vanilla Ruby on Rails)

Code: [Select]

4.years.ago.year.upto(1.year.from_now.year).reverse

And the result looks like:

Code: [Select]

[2023, 2022, 2021, 2020, 2019, 2018]

[CodingHare]

Oof. A developer wanting to use the database for this doesn't inspire confidence, to be honest. For just an example, here's how simple this should be (this is using vanilla Ruby on Rails)

Code: [Select]

4.years.ago.year.upto(1.year.from_now.year).reverse

And the result looks like:

Code: [Select]

[2023, 2022, 2021, 2020, 2019, 2018]

Damn Ruby is nice, that's so expressive and human readable.

[Rubic]

Python equivalent:

Code: [Select]

>>> import datetime; year = datetime.date.today().year; list(range(year+1, year-5, -1))
[2023, 2022, 2021, 2020, 2019, 2018]


[scottish]

Maybe the developer was a database guy?    When your only tool is a shovel, every solution is a hole...

[MustacheAndaHalf]

Given how specific the requirements were, if this were a question on Leetcode I might just dump the following Go code as my answer:

func RecentYears() []int {
  nowYr := time.Now().Year()
  return []int{nowYr+1, nowYr, nowYr-1, nowYr-2, nowYr-3, nowYr-4}
}

If someone actually made the number of years vary, I'd bother with a loop.

[MustacheAndaHalf]

The requirement - show a list of consecutive years in descending order from Next year to 4 years ago.
...
Developer turned in solution that was "put list of years in a database table & display that table". Upside would be if requirement changes we just change the list in the table. Downside is we've got an annual task to update this configuration table.
...

This seems like a trivial task that nobody would focus on, so maybe I am missing some context?  Maybe the database language makes this more difficult?

[dandarc]

The requirement - show a list of consecutive years in descending order from Next year to 4 years ago.
...
Developer turned in solution that was "put list of years in a database table & display that table". Upside would be if requirement changes we just change the list in the table. Downside is we've got an annual task to update this configuration table.
...

This seems like a trivial task that nobody would focus on, so maybe I am missing some context?  Maybe the database language makes this more difficult?

Why I was kind of surprised to see the "table" solution enough to ask how others would do it. Some additional context - dude didn't actually put the full 6 year range requested in the table or even test the screen this shows up on before declaring the change done. So didn't meet the spec on the display side and managed to break something that was working before (just with a longer list of years than customer wanted) in a not-at-all-subtle way.

[MustacheAndaHalf]

The requirement - show a list of consecutive years in descending order from Next year to 4 years ago.
...
Developer turned in solution that was "put list of years in a database table & display that table". Upside would be if requirement changes we just change the list in the table. Downside is we've got an annual task to update this configuration table.
...

This seems like a trivial task that nobody would focus on, so maybe I am missing some context?  Maybe the database language makes this more difficult?

Why I was kind of surprised to see the "table" solution enough to ask how others would do it. Some additional context - dude didn't actually put the full 6 year range requested in the table or even test the screen this shows up on before declaring the change done. So didn't meet the spec on the display side and managed to break something that was working before (just with a longer list of years than customer wanted) in a not-at-all-subtle way.

So something like this at performance review time?

"Problem solving ability: struggles with trivial problems, amplifying mistakes by not testing"

Although to be fair, performance reviews encompass whatever people can remember about the past year, rather than just a small assignment like this.  I used to work somewhere that employees gave feedback about each other, and I would have been nicer than the above comment.

[Paul der Krake]

Nobody thought to mention that there's a edge case around 0, i.e. there's no year 0.

If you were to run it 0001-07-22, it would go 2, 1, -1, -2, -3, -4.

You're all fired.

[PDXTabs]

Nobody thought to mention that there's a edge case around 0, i.e. there's no year 0.

If you were to run it 0001-07-22, it would go 2, 1, -1, -2, -3, -4.

There is in ISO 8601. Did the customer specify whether or not they wanted ISO 8601 dates? Because if not I think that it goes 2 CE, 1 CE, 1 BC, 2 BC, 3 BC, 4 BC.

[MustacheAndaHalf]

Nobody thought to mention that there's a edge case around 0, i.e. there's no year 0.

If you were to run it 0001-07-22, it would go 2, 1, -1, -2, -3, -4.

You're all fired.

Negative numbers are not valid years.

Unless you're running on a system that crashes a lot, you're running on Unix, where none of the years you mentioned exist.
"The Unix epoch is 00:00:00 UTC on 1 January 1970 (an arbitrary date)"
https://en.wikipedia.org/wiki/Unix_time

[scottish]

Nobody thought to mention that there's a edge case around 0, i.e. there's no year 0.

If you were to run it 0001-07-22, it would go 2, 1, -1, -2, -3, -4.

You're all fired.

Negative numbers are not valid years.

Unless you're running on a system that crashes a lot, you're running on Unix, where none of the years you mentioned exist.
"The Unix epoch is 00:00:00 UTC on 1 January 1970 (an arbitrary date)"
https://en.wikipedia.org/wiki/Unix_time

That's right, nothing happened before Unix time zero.

[MustacheAndaHalf]

Nobody thought to mention that there's a edge case around 0, i.e. there's no year 0.

If you were to run it 0001-07-22, it would go 2, 1, -1, -2, -3, -4.

You're all fired.

Negative numbers are not valid years.

Unless you're running on a system that crashes a lot, you're running on Unix, where none of the years you mentioned exist.
"The Unix epoch is 00:00:00 UTC on 1 January 1970 (an arbitrary date)"
https://en.wikipedia.org/wiki/Unix_time

That's right, nothing happened before Unix time zero.

Way to ignore context: "you're running on Unix", since you missed it.  And no, nothing happened on Unix before Unix existed.

[jim555]

SELECT TOP 4 tblYears.years
FROM tblYears
ORDER BY tblYears.years DESC;

[scottish]

Nobody thought to mention that there's a edge case around 0, i.e. there's no year 0.

If you were to run it 0001-07-22, it would go 2, 1, -1, -2, -3, -4.

You're all fired.

Negative numbers are not valid years.

Unless you're running on a system that crashes a lot, you're running on Unix, where none of the years you mentioned exist.
"The Unix epoch is 00:00:00 UTC on 1 January 1970 (an arbitrary date)"
https://en.wikipedia.org/wiki/Unix_time

That's right, nothing happened before Unix time zero.

Way to ignore context: "you're running on Unix", since you missed it.  And no, nothing happened on Unix before Unix existed.

Unix-centric much?

[MustacheAndaHalf]

Nobody thought to mention that there's a edge case around 0, i.e. there's no year 0.

If you were to run it 0001-07-22, it would go 2, 1, -1, -2, -3, -4.

You're all fired.

Negative numbers are not valid years.

Unless you're running on a system that crashes a lot, you're running on Unix, where none of the years you mentioned exist.
"The Unix epoch is 00:00:00 UTC on 1 January 1970 (an arbitrary date)"
https://en.wikipedia.org/wiki/Unix_time

That's right, nothing happened before Unix time zero.

Way to ignore context: "you're running on Unix", since you missed it.  And no, nothing happened on Unix before Unix existed.

Unix-centric much?

It seems like you didn't read my post, which leaves me quoting it back to you piece by piece.
"Unless you're running on a system that crashes a lot, you're running on Unix ..."

And in case you think I'm the one that's Unix-centric, take a look around at the internet.  80% Unix.
https://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Public_servers_on_the_Internet