AppleTV+ release its content very early in the morning Ireland time on the advertised date, which mean that it is available in the evening of the previous day in the United States. (This is a United States series).

It is so much confused it is saying on IMDB/TVmaze/Apple mid night air time likely next day 12:00 AM and my timezone is Europe/Athens but I am seeing they are saying This Friday 17th coming? but why specifically on TMDB date set different than all others platforms? It is completely look strange?

@alexanju said:

It is so much confused it is saying on IMDB/TVmaze/Apple mid night air time likely next day 12:00 AM and my timezone is Europe/Athens but I am seeing they are saying This Friday 17th coming? but why specifically on TMDB date set different than all others platforms? It is completely look strange?

None of the services you indicate give a time. They just indicate a date.

AppleTV+ release its new content very early on the advertised date Ireland time, which mean the evening of the previous day in the United States (This is a United States series).

If you are in Europe, it will be available for you on the date advertised by Apple.

The date you have set is in the EST time zone, which makes it Thursday, January 16th. However, Apple is officially releasing it on Friday, January 17th (early morning or the previous night let say whatever time is). Why not align it with Apple's official source? I find this confusing.

All our dates are based on the origin country of the series.

Apple release its content on the advertised date (January 17 in this case) very early in the morning Ireland time, which mean the previous day (January 16 in this case) in the evening in the United States.

The origin country of that series is the United States. Consequently, we should list the date it is available in the United States.

@superboy97 Based on this, wouldn't it be best if the timezone information is all in the response instead of blindly saying "2025-01-16"? This way we can adapt the rendering to the timezone in question where whoever is accessing the content in.

@afonsojramos said:

@superboy97 Based on this, wouldn't it be best if the timezone information is all in the response instead of blindly saying "2025-01-16"? This way we can adapt the rendering to the timezone in question where whoever is accessing the content in.

This will be of no use as with only a date and a timezone, you will not be able to do any calculations.

You will have to wait until an airdate field is added. There is an evolution planned, but no availability date for the moment.

@superboy97

I think @afonsojramos has a valid point, I think it feels the release_date and air_date fields lack of information on those dates to what time zone they belong to.

I think the best way to represent that would be using ISO 8601 format (2025-02-21T12:00:00+00:00) instead of using simply yyyy-mm-dd, because this makes really unpredictable to any client using the API how to process that information, because it would be relative to the country, networks, etc Instead using ISO 8601 the information on how to present the dates to the end-users will be tied along the date itself.

@francescostella said:

I think the best way to represent that would be using ISO 8601 format (2025-02-21T12:00:00+00:00) instead of using simply yyyy-mm-dd, because this makes really unpredictable to any client using the API how to process that information, because it would be relative to the country, networks, etc Instead using ISO 8601 the information on how to present the dates to the end-users will be tied along the date itself.

As indicated in the message above, this is currently not possible. The system doesn't have the information about the airdate. And with only a date and a timezone, you can't do anything.

@francescostella said:

I think the best way to represent that would be using ISO 8601 format (2025-02-21T12:00:00+00:00) instead of using simply yyyy-mm-dd, because this makes really unpredictable to any client using the API how to process that information, because it would be relative to the country, networks, etc Instead using ISO 8601 the information on how to present the dates to the end-users will be tied along the date itself.

Sorry, that was exactly what I meant. Sorry for not being clearer.

@superboy97 said:

As indicated in the message above, this is currently not possible. The system doesn't have the information about the airdate. And with only a date and a timezone, you can't do anything.

If it is not possible, I do not understand how it makes sense to reply with a conversion of the advertisedDate instead of the advertisedDate itself.

@afonsojramos said:

If it is not possible, I do not understand how it makes sense to reply with a conversion of the advertisedDate instead of the advertisedDate itself.

Because all our release dates for series are based on the origin country of the series.

@superboy97 said:

@afonsojramos said:

If it is not possible, I do not understand how it makes sense to reply with a conversion of the advertisedDate instead of the advertisedDate itself.

Because all our release dates for series are based on the origin country of the series.

I understand that. But I think that shouldn't be taken into account, because on most occasions you'll have situations where you're returning a date where it will be available for 3 hours or so, because the offset will always be caused by timezones.

Example: Returning "2025-01-16" when it is only available from 9PM Instead of returning "2025-01-17", where you know that it is going to be available for the span of the 24h because that is the advertised date after all.

@travisbell @superboy97

There is no difference between :

• returning "2025-01-16" for something that will be broadcasted on regular TV on that date at 9:00pm
• returning "2025-01-16" for something that will be available on a streaming service starting from that date at 9:00pm

None of them will be available during all the 2025-01-16 day.