If it’s not broken, why fix it?
If you change something, why not test it first before giving your users something broken?
Server Version#: 1.26.0.5715
(Edit: I didn’t even bugcheck my own thread post, apparently. Changed server version from 1.26.0.5725 to 1.26.0.5715)
What issue are you having? Your message isn’t clear.
The issues I’m aware of with Originally Available At and Year appear to be resolved in 1.26.1.5772.
1.26.1.5772. Is still beta, right?
Yes.
I think a lot of people routinely use betas that shouldn’t, because they are then crabby when there are bugs.
But 1.26.0 was public and had these issues. Bugs happen in public releases too. Such is life.
So if you’re using 1.26.0 right now, and are having issues with Originally Available At and Year, and don’t feel like waiting … 1.26.1.5762 is a relatively small update, and appears to resolve those specific issues.
Dates are just cosmetic, so I’ll wait for the public release.
Hah, that’s what I said too - that it’s entirely cosmetic!
Turns out this can also affect people using Smart Playlists or filtering by Year.
I agree; if you aren’t impacted …
Do you happen to know why plex are messing about with the date formats within the db schema? I come from a software background and the changes they are making do not make sense to me. Appears to be change for changes sake!
It also seems haphazard as only some tables have changed.
I guess this is the real question I was getting at in a crabby way.
Are the tables changing? I thought it was just a UI error when converting the UTC date (in the database) to local time.
The format of the dates in the db have changed for some tables but not all.
Datetime fields in some tables, including metadata_items, have been changed from a text format YYYY-MM-DD HH:MM:SS to a unix-style epoch seconds format.
Thanks. How is that fixed (when I update). Do I need to do a metadata refresh?
When you update, Plex will perform a database migration automatically, converting the values in those fields to the new format.
These bugs were in the UI and PMS internal APIs - PMS wasn’t consistently updated to use the new date format!
The objectively correct way to store date / time.
Still comes down to why?
Only reason I can’t think of is that it makes it (slightly) more complicated to see the human readable dates when reviewing the db directly.
Could be part of the integration they are working on with other streaming services.
Textual dates are gross, but at least it was a sane ISO8601 subset format before.
Any bets about 2038-01-19 03:14:08?
The database isn’t intended to be a human-consumable interface. This doesn’t bother me at all.
Internally they were probably converting the date-text to an epoch-style string every time they did a comparison, and then back again for storage.
Makes more sense for the computer to store computer-things in a computer-readable format.
Sure but seems like a lot of development effort just to rework internal date formats. Many other things would seem more important but sure what do I know… 
2 weeks ago I came on the forums to tell complain about this. I am so glad other people are seeing what I did.
I wasn’t there, but I’ll bet $2 it went like this:
"I’m working on feature X (or bug Y) which uses dates. This is twice as hard as it should be, because we’re using these dumb text dates in the database.
I could also use the dumb text dates in the new feature, but that would just be perpetuating the problem.
If I refactor this code to use sane dates, that will help me get my work done faster - and remove some technical debt in the process.
And I’ll feel more job satisfaction because I’ve improved the code a bit, instead of just kicking the can down the road."
I’ll bet another $1 that they’re really annoyed that they introduced bugs that made it into public view.
