fix(server): do not return year with weird timezone info i.e before 1890

[alextran1502]

Some older years come with a timezone JS time doesn't recognize, rendering an invalid date. This PR adds the year cutoff for queries that could have trouble with the said years

[mertalev]

You can move that to the subquery for generate_series, wrapping it in greatest.

[alextran1502]

You can move that to the subquery for generate_series, wrapping it in greatest.

I am not sure I completely get what you mean. Understand the part of moving it into generated_series, isn't greatest will get the latest year?

[mertalev]

I mean that you can do something like greatest(1850, subquery), where the subquery returns the earliest year.

[bo0tzz]

I don't think we should just straight up not return things like this. If there are timezones that JS can't handle, I think it'd be better if we just drop the timezone part there altogether. As it stands, this change would mean that assets will just disappear.

[danieldietzler]

Strongly agree with @bo0tzz.

[jrasm91]

Maybe it would be better to just unset the timezone for these instead. Or, add more validation around what timezones we accept when the date is this old

[NicholasFlamy]

According to Wikipedia the oldest driving photograph is from 1826:
History of the Camera:
"View from the Window at Le Gras (1826), the earliest surviving photograph[10]"

Edit: 1890 is a good cutoff though because realistically no one had a camera until after that.

[bo0tzz]

I think there's more to the consideration than just what might be the oldest camera photograph. As an example, people might want to store scans of older art or documents, not to mention the possibility of a file just having bad metadata with a year far in the past - assets disappearing unexpectedly will always cause issues somewhere.

[Snowknight26]

Are there any examples of the dates/timezone combinations that supposedly have issues?