You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I don't work with this repo but I encountered the exact datetime from the link above, in a different context. I also resolved the issue. Since one of the things I did before finding the answer, was google search the very specific number 11651379494838206464, and find an issue closed within the past half a year without resolution, I figured I would share the result.
11651379494838206464 (Tuesday, March 21, 2339 10:18:14.838 PM)
This datetime is what you get when you stuff midnight on 1/1/1 (that is year 0001) into a uint64 nanos time. Since 2^64 nanoseconds is around 585 years, you get the result mod that interval. That operation will turn it into either March of 2339 (if handling as unsigned) or August of 1754 (if handling as signed), both values show up in the linked issue. So the "unexpectedly late expiration timestamp" is actually a significant magic number date, just really obfuscated. Look for a source of magic timestamp "midnight on 1/1/1" in the code.
cc Kraney except I can't really find a way to reach him, and his own fork of this repo doesn't have issues enabled.
The text was updated successfully, but these errors were encountered:
cadence-workflow/cadence#4077 archived
I don't work with this repo but I encountered the exact datetime from the link above, in a different context. I also resolved the issue. Since one of the things I did before finding the answer, was google search the very specific number 11651379494838206464, and find an issue closed within the past half a year without resolution, I figured I would share the result.
11651379494838206464 (Tuesday, March 21, 2339 10:18:14.838 PM)
This datetime is what you get when you stuff midnight on 1/1/1 (that is year 0001) into a uint64 nanos time. Since 2^64 nanoseconds is around 585 years, you get the result mod that interval. That operation will turn it into either March of 2339 (if handling as unsigned) or August of 1754 (if handling as signed), both values show up in the linked issue. So the "unexpectedly late expiration timestamp" is actually a significant magic number date, just really obfuscated. Look for a source of magic timestamp "midnight on 1/1/1" in the code.
cc Kraney except I can't really find a way to reach him, and his own fork of this repo doesn't have issues enabled.
The text was updated successfully, but these errors were encountered: