time series forecasting with hourly data

[#1]

I just saw a very interesting webinar by Jian Cao on time series forecasting, so I thought I'd give it a try with a test dataset in which I logged temperature every three hours for several years. However, when I enter the date and time into the time stamp I get an error message: unsupported time format. I tried every single format under the "time" input options for continuous variables. Certainly there is a way for JMP Pro 16 to interpret hourly daily across multiple days, right? 

[#2]

Hi Anderson,

It seems that the Time Series Forecast platform needs either a date or a simple numeric timestamp. I think it is not working with your time column because it is a date-time format.

I converted your timestamp to numeric (Format = Best) and the Time Series Forecast now accepts it (attached). I think this numeric timestamp is seconds since 1 Jan 1970 or something like that.

I am not sure why Time Series Forecast does not accept your date-time format. It might be a good idea to send this one to JMP Technical Support (support@jmp.com) so they can investigate and potentially log as a defect.

I hope that helps,

Phil

[#3]

Just to be factually correct, the origination time( epoch ) for JMP date time values is 12 AM, January 1, 1904.  The best explanation I have read, comes from Pat Lavezza on the LabVIEW forum.  LabVIEW uses the same epoch as JMP, with the origins going back to Apple computers

"Here's the deal with January 1, 1904. Most (all?) operating systems store time as the number of seconds ( or microseconds, etc.) since a certain time. This time is call the epoch. The number of seconds that the Mac could store covered about 130 years. The programmers wanted the system to be able to cover the birthdays of most users, so the epoch needed to start in the early 20th century. So why not start at January 1, 1900?

The Macintosh designers needed to squish a lot of code into a very small amount of ROM/RAM. They were looking for any kind of tweak that could save them some room. The code to turn the number of seconds since the epoch into a date (like March 29, 1973) needs to know how many days there are in a year. Which means you need code to determine if a year is a leap year.

A year is a leap year if it is a multiple of 4 unless it is a multiple of 100 except if it is also a multiple of 400. So, 1900 wasn't a leap year (multiple of 100), but 2000 was (multiple of 100, but also a multiple of 400). By avoiding the year 1900, the Mac designers never had to worry about the 100/400 part of the leap year rule (because the 130 year span would only cover 2000 which was a leap year). If the year was a multiple of 4, it was a leap year.

So why not 1901 or 1902 or 1903? By starting with a leap year they didn't need an 'offset', just another way to save a little bit of space.

And since LabVIEW started on the Mac, it inherited some of those quirks."

FYI, SAS epoch is January 1, 1960

[#4]

@txnelson Who knew? Thanks for sharing this little bit of history. I think "Jeopardy" writers/producers could create an entire category out of the nuggets in that explanation. 

[#5]

That's an interesting tidbit, thanks Jim. Of course JMP was originally designed for Mac's, so it makes sense the connection with the Mac.

[#6]

Thank you both for looking into this, and for the explanation. The only problem with converting to the "best" format is that, for some reason, when you try to back-convert from the number string to the date and /or time (for when you forecast out), the date and time are incorrect! For instance, when you forecast out 1000 seconds using this dataset and then convert the "ahead" times back to the time format, the year is 1835 instead of 2021. And Jim is right: the most recent "second" value is 3693752220, meaning that the clock started 117 years ago, so 1904. I will ask technical support is there is a work-around that doesn't involve using number of seconds since 1904 in my calculations.