I was able to also create a rule to display a Gregorian date in the format MM-DD-YYYY from a Unix timestamp. This works to convert a Unix Timestamp back to the date produced by the Rule to calculate a Unix timestamp from a Gregorian date, or any Unix timestamp, including ones produced by the Time variable Now(). However, when I retrieve the Now() variable from the system, it appears to be pulling GMT time even though my Hubitat is set to US/Eastern.
The actual math driving these calculations works for a very large range of dates, however, it appears as if Hubitat may be a 32 bit platform, or the Number variables are limited to 32 bit, as entering any Unix timestamp for a date beyond January 19, 2038, produces a date that circulates back counting up from December 14, 1901 where it left off at January 19, 2038, which is known as the "Year 2038 problem" for Unix type systems. Note that the Rule to create the Unix timestamp from a Gregorian date just stops incrementing the Unix timestamp beyond January 19, 2038. Also note the same is true for dates prior to December 14, 1901 for the same reason, not that anyone is likely interested in a Unix timestamp with that early of an underlying date.
To show how it works, I triggered the U->G rule to trigger from a change in the variable that outputs the G->U conversion. The result is that a change in the Gregorian target date in the Global Variables screen, almost immediately displays the Unix timestamp, and a decoded Unix timestamp confirming the original date entered.
Global Variables:
Note the GV_Decimal_1 variable that is displaying a now() Unix timestamp, and that converts to ~45minutes after midnight on 5-10-2020.
Local Variables:
Rule:
Entering a date of 02-29-2040, produces Unix timestamp stopped at January 19, 2038 :
