Youtube decade bug? Takedown notice: dec 31, 1969

[Ed.Kloonk]

[aix]

I'm not in a position to watch the video right now, but I think it's unlikely to be a "decade bug".  I think it's probably some zero-initialised Unix time converted to someone's local timezone.

https://en.wikipedia.org/wiki/Unix_time

I imagine this totally misses the point of your post.

[Ed.Kloonk]

I imagine this totally misses the point of your post.

You got it!

 


 

[vwestlife]

It is because of the UNIX epoch. Midnight GMT on 1/1/1970 (which UNIX represents as a time/date value of zero) is equal to 4:00 PM 12/31/1969 in California (where YouTube is based). So somehow the copyright takedown date got entered as zero and this is what it gets displayed as.

The latest reply I got from TeamYouTube on Twitter is "Sorry for the trouble -- we're taking another look at this and will share updates asap."

[Ed.Kloonk]

How many years will it take for time to loop back around to year 1969?

9949 ?

Prolly as long as it will take for you to get a satisfactory response from Youtube. 

[Ed.Kloonk]

[vwestlife]

Speaking of that song and YouTube, Rick Evans was furious about Denny Zager getting credit for writing the music, and blasted the comments section of anyone who uploaded that song to YouTube, insisting that he wrote the whole thing and deserved all of the credit for it, until he passed away in 2018.

[Ed.Kloonk]

Speaking of that song and YouTube, Rick Evans was furious about Denny Zager getting credit for writing the music, and blasted the comments section of anyone who uploaded that song to YouTube, insisting that he wrote the whole thing and deserved all of the credit for it, until he passed away in 2018.

Folk singers are funny. They tout living in peace and kindness and sharing everything. Until someone pinches their song...

[Red Squirrel]

How many years will it take for time to loop back around to year 1969?

9949 ?

Prolly as long as it will take for you to get a satisfactory response from Youtube. 

Actually less than that.   time_t is signed so half of it is wasted which does not help.  It will roll over in 2038!   Not sure what the solution is, I think this issue will be worse than Y2K.  They could make a new one that is 64bit unsigned but honestly I think an even better system is in order, rather than counting seconds since a given time to me it should just be a yyyy-mm-dd-hh-mm-ss-ms system.  Without sitting down right now to figure it out,  I imagine all that information can be compressed into a 64 bit int and cover practically unlimited time.    But no matter what, the hard part is dealing with existing systems.  C/C++ for example uses time_t and without having to incorporate extra libraries you can't easily change it.  Though perhaps C/C++ itself is due for an update.  There's lot of core/standard libraries that could use updating, like adding ipv6 support etc too.  Yeah you can add add-on libraries that you have to specificity link to but I'm talking about the core ones.  On  embedded systems it's important to keep things very small and simple.

What I find odd is how someone designed these time systems without making it future proof from the get go.   It's one thing to not account for a certain thing when coding, but everybody knows time goes forward, so it's not like the fact that a certain date will happen is an unforeseen circumstance. 

[langwadt]

How many years will it take for time to loop back around to year 1969?

9949 ?

Prolly as long as it will take for you to get a satisfactory response from Youtube. 

Actually less than that.   time_t is unsigned so half of it is wasted which does not help.  It will roll over in 2038!   Not sure what the solution is, I think this issue will be worse than Y2K.  They could make a new one that is 64bit unsigned but honestly I think an even better system is in order, rather than counting seconds since a given time to me it should just be a yyyy-mm-dd-hh-mm-ss-ms system.  Without sitting down right now to figure it out,  I imagine all that information can be compressed into a 64 bit int and cover practically unlimited time.   

time_t is usually signed

a 64 bit time_t is plenty, it rolls around ~292 billion years from now, in ~2 billion years from now the 32 bit tm_year rolls around

[SiliconWizard]

I don't think time_t is meant to really hold dates anyway. As a time arithmetic type (to compute time difference for instance), it must be used with due care.

The type defined in the standard to hold calendar time is "struct tm", which defines all of its fields as "int". The year is the offset from 1900. That's plenty on platforms where int is at least 32-bit, and still not too bad even on platforms where int is 16-bit!

The conversion functions between time_t and struct tm are up to the environment I guess... and I don't doubt some environments are not able to fully convert a struct tm to time_t without losing something in the process...

[Red Squirrel]

How many years will it take for time to loop back around to year 1969?

9949 ?

Prolly as long as it will take for you to get a satisfactory response from Youtube. 

Actually less than that.   time_t is unsigned so half of it is wasted which does not help.  It will roll over in 2038!   Not sure what the solution is, I think this issue will be worse than Y2K.  They could make a new one that is 64bit unsigned but honestly I think an even better system is in order, rather than counting seconds since a given time to me it should just be a yyyy-mm-dd-hh-mm-ss-ms system.  Without sitting down right now to figure it out,  I imagine all that information can be compressed into a 64 bit int and cover practically unlimited time.   

time_t is usually signed

a 64 bit time_t is plenty, it rolls around ~292 billion years from now, in ~2 billion years from now the 32 bit tm_year rolls around

Err right meant signed.   The one that can go negative lol.

[station240]

Could be someone wrong a function that calculates the difference in time, but returns -1 (false) if unsuccessful.

[vwestlife]

This is getting more and more FUBAR. I used YouTube's online video editor to completely remove the song that was causing the copyright claim (a 26-second clip of Gino Vanelli's "I Just Wanna Stop"), thinking that would remove the claim -- but it didn't! So now YouTube is threatening to take down the video and give me a copyright strike -- whenever it decides it's December 31st, 1969 again -- for a piece of music that isn't even in the video anymore!
 

[vwestlife]

Finally somewhat of a substantive response from YouTube:

Hi Kevin,
I hope this email finds you well.

I just received an update from our internal team. I was able to confirm that there is currently a bug which caused the wrong date (December 31st, 1969) to display in your copyright notices. Our Engineering team is already aware of this and they are currently working on a fix. Unfortunately, I'm not able to provide a solid estimate on when this will be fixed.

Since you have already removed the claimed material from your video, you may reach out to SMEdisputes@gmail.com to release the claim on your video. If you were previously monetizing the video, your monetization settings will be restored automatically when all claims on your video are released.

We appreciate your patience and your cooperation!
Let me know if you have other concerns.

Regards,
Kristine
YouTube Support Team

That "smedisputes@gmail.com" e-mail address is total bullshit. Do you really think any corporation as large as Sony Music Entertainment would use freakin' GMAIL for their official company communications!? No, it's just some burner address they made up to satisfy YouTube's requirements and which they never actually check. I've tried contacting that e-mail address in the past regarding other videos and never received a response from them. The "peeleremi@gmail.com" address that YouTube will give you for contacting EMI Records (UMG) is equally fake and useless.

[vwestlife]

Success! Today YouTube Support finally escalated my problem to someone who could actually fix it, and now the copyright claim has finally been removed from the video. Let's hope it stays that way!

[Red Squirrel]

it's a piss off how long it takes them to react.  You still end up losing tons of views and revenue because of their own screw up.

[vwestlife]

And now a Family Guy video on YouTube is claiming it premiered on December 31st, 1969 (or January 1st, 1970, depending on your time zone):

[Ed.Kloonk]

Derek points out an interesting statistic regarding percentage of independent creators now and ten years ago.