Premiered date is showing up wrong

[softworkz 3335]

I already submitted a fix for it: https://github.com/MediaBrowser/Emby/pull/1982

..and also suggested an alternative solution there.

 

I wonder why this hasn't been addressed yet, because the current handling of these dates is indisputably wrong.

[heula 189]

And again I will ask nicely when this bug will be fixed?

The topic excist since 3 october 2015 and the bug is there much longer. Please fix this.

 

Again, only happens with files that are sorted by there date in the name and have no season and episode number in the name.

 

Thanks in advance.

[heula 189]

Because this fix will take another 25 years  I have created my own workaround.

 

I have created a batch file that first set the time zone to Eastern Standard Time, than it starts the emby server and after starting the emby server the time zone is set back to W. Europe Standard Time.

 

I have seen this works great because the emby server thinks we are in the Eastern Standard Time Zone and my PC is set to W. Europe Standard Time Zone. All episodes are sorted correctly at the right date.

 

This batch file starts every time my PC start up and I disbled start up in the emby server setting.

 

This is my batch file.

tzutil /s "Eastern Standard Time"

TASKKILL /F /PID MediaBrowser.ServerApplication.exe

timeout 5

start C:\Users\Alex\AppData\Roaming\Emby-Server\System\MediaBrowser.ServerApplication.exe

timeout 20

tzutil /s "W. Europe Standard Time"

Off Course I still think this needs to be fixed but for now I can live with it.

[schumi2004 9]

Is this issue still present because i also noticed wrong première date today.

[Luke 37057]

this issue is related to a very specialized scenario - auto-organize with a date in the file name. if that doesn't apply to you then whatever you're seeing is not related. thanks.

[schumi2004 9]

@@Luke, All my files don't have a date in it and they are all 1 day of regarding premiered date.

[softworkz 3335]

this issue is related to a very specialized scenario - auto-organize with a date in the file name. if that doesn't apply to you then whatever you're seeing is not related. thanks.

 

There's another thread about incorrect premiere dates due to incorrect time zone conversions, though. And that issue is in fact still unsolved afaik.

[Jobber8742 9]

There's another thread about incorrect premiere dates due to incorrect time zone conversions, though. And that issue is in fact still unsolved afaik.

 

I run into this when I create my own metadata. I like to create sporting events as tv seasons, which requires me to input all the metadata. Whenever I put in a date, it always shows up as one day before in all the apps. I can manually modify the .nfo file and fix it though.

[softworkz 3335]

Then it's related to the other known bug I've been referring to: Emby performs a timezone conversion on your date values. It assumes that the dates in your nfo files are relative to your local time zone and converts them to UTC. This conversion can easily result in a different date if you're living in a time zone with a positive offset (UTC+x).

 

This behavior is a bug in Emby as I laid out in various posts before:

• The "Premiere Date" value is a date and nothing more. It doesn't have a time component.
  ​As such it is incorrect to apply timezone conversion
  ​
• Even if it would have a time component (there may be other fields in the nfo or data returned from a metadata provider), it would be incorrect to assume that the values in the nfo are specified in local time (timezone in which Emby Server is configured to run). E.g. a metadata provider may return a "FirstAired" value including time for a series episode. This datetime value would be relative to the local time of the (e.g.) US broadcast station.
  ​Currently Emby would assume that this returned value is relative to your local timezone and convert it from that local timezone back to UTC. That result is totally wrong, of course.
  Due to this the "UTC" values stored in Emby Server vary by the Server's time zone (while UTC values should actually be constant all over the world)

[softworkz 3335]

Now, I got a theory why it hasn't been fixed yet: This bug affects half of the world, only.

 

Following example:

• An nfo file contains a PremiereDate value of 2016-12-01
  ​(could also be a value returned by another metadata provider)
  ​
• Emby treats this as datetime: 2016-12-01, 0:00 am and assumes it to be relative to the local time zone (of Emby Server) and converts it from there to UTC
  ​
• Now there are actually two different cases to look at:
  • Your timezone is UTC-X: e.g. if you live in New York, US, then your time zone is UTC-5
    ==> 2016-12-01, 0:00 am local gets converted to a UTC value of 2016-12-01, 5:00 am
    ​
  • Your timezone is UTC+X: e.g. if you live in Berlin, Germany, then your time zone is UTC+1
    ==> 2016-12-01, 0:00 am local gets converted to a UTC value of 2016-11-30, 11:00 pm

 

​​Conclusion: Although this bug is of general nature, it noticeably only affects users in timezones with a positive UTC offset!

​In the UI, Emby does not display a time component for the PremiereDate, so for users like in the US, everything seems right.

 

​But for the world living to the East of Greenwich (UTC plus X), Emby is showing incorrect dates.

 

[haggis663 0]

It would be good to get this sorted out as living in a timezone of UTC+10 gives all the upcoming shows to be a day out. i.e. shows airing today are shown as yesterday.

[simonk83 7]

Just started using Emby and ran into this issue immediately, but from reading through this thread it doesn't look like there's much desire to fix it.

 

This has nothing to do with dates in filenames, it's just as already mentioned a few times, due to positive UTC offsets (I'm in Australia) the tvdb dates are all off by 1 day.   It's probably a 5 minute fix, just need someone to prioritize it for the sake of those not living in America (there are a few of us you know ).

[heula 189]

America first 

[simonk83 7]

Bump

[simonk83 7]

Bump

[heula 189]

Bump

You can bump all you want. This issue exists voor almost 2 years now and nothing has changed so far!

[simonk83 7]

You can bump all you want. This issue exists voor almost 2 years now and nothing has changed so far!

 

Hence the bumps

[Luke 37057]

This is on our list, nothing is forgotten. This is just a hard one because it may require us to change our api with Emby apps, so that's why it keep getting pushed out. Also, to my understanding the last remaining issues are related to files that are named by date and not with episode numbers. I did some testing a few months back and could not reproduce any issues outside of that.

[simonk83 7]

Hi Luke,

 

Nothing to do with dates in file names, this happens regardless. It's just a positive timezone offset issue. Glad it's still on your radar though

[Luke 37057]

Hi Luke,

 

Nothing to do with dates in file names, this happens regardless. It's just a positive timezone offset issue. Glad it's still on your radar though

 

Then most likely you're issue is something else and you're jumping into this thread because it sounds like the same thing. The best thing to do is start from the beginning and see how to report a problem. thanks !

[simonk83 7]

To be fair, I think one guy in this thread complained about the dates in file names and pretty much everyone in the rest of the 5 pages is people with my issue.

 

The guy at the top of this page sums it up pretty well.

Edited February 3, 2017 by simonk83

[Luke 37057]

To be fair, I think one guy in this thread complained about the dates in file names and pretty much everyone in the rest of the 5 pages is people with my issue.

 

The guy at the top of this page sums it up pretty well.

 

I would like to hear from you from the beginning what your issue is.

[simonk83 7]

Fair enough, just heading home from work, give me a bit and I'll put something together.

[Luke 37057]

Fair enough, just heading home from work, give me a bit and I'll put something together.

 

Thanks !

[simonk83 7]

Thank you