Dates before 1/1/1970 at 7:00 PM

verified
#1

Background: I’m using the datetime variable in a non standard way, but something that could be useful for others. I set a date/time variable to a zero date. I was trying to use 1/1/1900 12:00:00.000 AM as I have done something similar with dates in the past using excel. I then can add time to this variable so that I can see how long something has been running. In my case, I use it for the HVAC systems and when a system has been running for 30 days total, I get an alert to change the filter.

Steps to replicate behavior:

  1. Open Piston to Edit mode
  2. Click add new global variable
  3. Select type “Date and Time”
  4. Enter any variable name
  5. Select Value (for initial value)
  6. pick any date/time before 1/1/1970 7:00 PM
  7. Click add

Actual Behavior
Date / time will be set to a date other than picked date

Desired Behavior
Date/Time stays at selected date/time

#2

So the correct behavior here assuming that the value is stored as a Unix timestamp where zero is represented January 1, 1970 is to allow negative numbers for dates before 1970. In general, these timestamps should be able to represent 136 years before and after 1970.

There could be any number of places rejecting or mishandling the negative number, it might be tough to track down but what you’re seeing certainly is a bug.

Regarding your use case, this is better stored in a regular number. Each time the HVAC stops running, add the total length of the current run to a numeric variable. To determine when the running time has crossed your threshold, rather than looking for a specific date in the year 1900 you can check when the total running time has surpassed the total number of seconds in 30 days.

#3

I already have a workaround. I’m using a later date as the staring point. I did want to make sure that I understood your suggestion. I can take two date/time numbers and subtract them in a formula and put the results in a number variable (decimal, I assume). This is because the UNIX time 0 is 1/1/1970 at 12:00:00.000 and each second past that time is 1 whole number and each part of a second past that time is +1 and each day is 86400 seconds. So if I am checking for a condition after something has cumulatively run for 30 days, I am checking for 86400 * 30. Right?

#4

Yep, that is correct.

#5

I always thought timestamps increased 86,400,000 times per day…
(24 hours * 60 minutes * 60 seconds * 1000 milliseconds)

For example, for me:
(datetime($sunset)) - (datetime($sunrise)) = 48,370,000 (about 13.4 hours)
This translates to 86.4 million per day, or 2.592 billion every 30 days