Sample JavaScript for created and lastUpdated incorrect

[dmdabbs]

In our CMP Forum in Slack, Najdan Tomic noted the sample code added to the created and lastUpdated field descriptions would not result in a GMT 00:00:00 value. The sample code should be adjusted to avoid further inquiries and possible incorrect implementations for those not using the community tclib (which does not use the sample code).

Najdan Tomic 9:47 AM Hi everyone! We are trying to implement changes related to created and lastUpdated - https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Fram[…]%20-%20Consent%20string%20and%20vendor%20list%20formats%20v2.md There is a JavaScript example for creating timestamp Math.round((new Date(new Date().getUTCFullYear(), new Date().getUTCMonth(), new Date().getUTCDate(), 0, 0, 0)).getTime()/100) First thing we notice is it's divided by 100 Second it will return time in our Local zone, for GMT +1 it will return GMT: Thursday, January 20, 2022 11:00:00 PM but new changes specify that hours, minutes and seconds are not needed anymore. Is this correct? (edited)

Regarding division by 100, I explained that the fields are specified as decicesond values.

cc: @anderagakura

[dmdabbs]

Najdan followed up in Slack to note that the spec, after our recent PR, does not refer to deciseconds.

I believe this is an issue since we reduced epoch seconds to fit them into the 36 bits we allocated to holding the integer values. Also the new 1.4.0 library pre-release retains the decisecond handling. Here is my response from Slack. Can someone check my work and verify so we can ensure the spec and library are accurate and aligned?

Thank you again for your keen eyes, Najdan. We've used decisecond integer values for date encoding because, quoting the v1 spec, Deciseconds fits into 36 bits with enough precision to record a user's consent action timing.

So I believe we need to restore the deciseconds mentions to the v2 spec.

// tclib encoders: https://github.com/InteractiveAdvertisingBureau/iabtcf-es/tree/master/modules/core/src/encoder/field
//
68719476735 = parseInt('111111111111111111111111111111111111', 2);

// example epoch seconds from JavaScript UTC date, 
var date = new Date(); 
1642809600000 = Date.UTC(date.getUTCFullYear(), date.getUTCMonth(), date.getUTCDate());

By dividing the epoch seconds values by 100 we're able to fit them into 36 bit width.

cc: @a2intl , @anderagakura

[anderagakura]

So following the comments and Slack, in Consent string and vendor list formats v2 page, we should remove Math.round((new Date(new Date().getUTCFullYear(), new Date().getUTCMonth(), new Date().getUTCDate(), 0, 0, 0)).getTime()/100) and apply this change Math.round(Date.UTC(new Date().getUTCFullYear(), new Date().getUTCMonth(), new Date().getUTCDate())/100).

Right?

[Najdan]

And note that deciseconds are used instead of milliseconds.

Also, the timestamp must be based in UTC time in order to get a consistent millisecond decisecond value across the time zones.

[anderagakura]

@Najdan @dmdabbs : Here is the PR 314

[anderagakura]

Issue closed due to the merge of the PR 314