The Date content type can be interpreted as a Number, which yields a Unix time value. However, the reverse does not work. A Unix time value interpreted as a Date does not yield a valid Date, even though the UI is happy to let you specify that interpretation. Nor can a Date be initialized with a Unix time as the “Specified Date”.
Many web service APIs use Unix time values and it seems awfully cumbersome to make those into Date content types. Currently the best I’ve found is to create a Date initialized with the string “January 1, 1970 00:00:00 UTC”, followed by an Adjust Date, adding the desired Unix time value as seconds. Ugh.
Is there something I’m missing? I’m workflow/Shortcuts novice.
Like all time, it’s an offset measurement from a fixed point that’s agreed by a convention. The only issue is that Shortcuts doesn’t (as far as I know) offer an action that will convert this natively so you always have to do a date adjustment calculation; as you noted. But it is easy enough to effectively create one that you can re-use.
Yes, that is the date manipulation I’m using now, but the sample does answer a question bubbling up the stack as I’m learning Shortcuts, which is how to factor out bits of workflows into functions. So thanks!
I may file a radar about not being able to round trip a Date to a Number and then back to a Date.