Epoch time useage unclear

[neilh10]

In loggerBase.cpp the useage of Epoch time is confusing.

I've clarified it by adding T0 for true Epoch Time, and Tz for when corrected for local time.

The following is actually using Tz ...

uint32_t Logger::getNowEpoch(void)
{
    uint32_t currentEpochTime = zero_sleep_rtc.getEpoch();
    // Do NOT apply an offset if the timestamp is obviously bad
    if (isRTCSane(currentEpochTime))
        currentEpochTime += ((uint32_t)_loggerRTCOffset) * 3600;
    return currentEpochTime;
}

I've updated to the following and could do a PR if of interest.

uint32_t Logger::getNowEpoch(void)
{
  //Depreciated in 0.23.4, left in for compatiblity 
  return getNowEpochTz();
}

uint32_t Logger::getNowEpochT0(void)
{
  uint32_t currentEpochTime =  zero_sleep_rtc.getEpoch();
  if (!isRTCSane(currentEpochTime))  {
    PRINTOUT(F("Bad time, resetting clock."),currentEpochTime);
    setNowEpochT0(currentEpochTime);
    currentEpochTime=EPOCH_TIME_20200101_SECS;
  }
  return currentEpochTime;  
}

uint32_t Logger::getNowEpochTz(void)
{
  return getNowEpochT0() + ((uint32_t)_loggerRTCOffset)*3600;
}

Possibly also for the following to use an "Ep2k" if it really is from 2000Jan01 - though I haven't worked through this yet.

// from January 1, 1970 00:00:00 UTC) into a DateTime object

DateTime Logger::dtFromEpoch(uint32_t epochTime)
{
    //Depreciated
    return dtFromEpochTz(epochTime);
}
DateTime Logger::dtFromEpochT0(uint32_t epochTimeT0)
{
    DateTime dt(epochTimeT0);
    return dt;
}
// This gets the current epoch time (unix time, ie, the number of seconds
// from January 1, 1970 00:00:00 UTC) and corrects it for the specified time zone
DateTime Logger::dtFromEpochTz(uint32_t epochTimeTz)
{
// The DateTime object constructor requires the number of seconds from
// January 1, 2000 (NOT 1970) as input, so we need to subtract.
    DateTime dtTz(epochTimeTz - EPOCH_TIME_OFF);  
    return dtTz;
}

[aufdenkampe]

@neilh10, I did a little work on adding a markedEpochTimeUTC in #324 with commit 254ce7d on Aug. 26, which should now be in Master.

I had a need for the Ubidots publisher. Perhaps that work is relevant to this.

[neilh10]

@aufdenkampe thanks for the heads up. I saw some of them and will check it out.

Generally I made changes to help me with the modules and put this discussion out there for clarity, and happy to do some of the work and make it clearer if it would help.

[neilh10]

So looking at it, I'm finding I need to trace the assumptions with the usage of time - epochTime format, which is also then repeated in DateTime dt. (y2k)

My solution adjusts naming.
I'm guessing you've run into a separate issue, and added another 32bits markedEpochTimeUTC to solve it.

void Logger::markTime(void) {
    Logger::markedEpochTime    = getNowEpoch();
    Logger::markedEpochTimeUTC = markedEpochTime
                                 - ((uint32_t)_loggerRTCOffset) * 3600;
}

The epochTime format is nice for computing - but a large number challenge for human decoding.

Perhaps the qu to ask, "in an ideal world, when should the local offset be considered?".
Ideally, only when it translates to HumanReadable format should the offset be added.
But of course a lot of debugging in the code use the Tz.

In the code "time" is mostly Tz, and then sometimes T0 - so why not have it clear, and it keeps it backward compatible.

The problem gets more of headache when using the SAMD with its internal volatile RTC based on the year 2000 (y2k?), and external persistent RtcPhy, and then keeping them in sync. Its been a big headache, so trying to help other people that follow.

[SRGDamia1]

I'm fine with renaming, or re-thinking when Tz vs UTC is used. I'd prefer "TimeUTC" or something similar rather than "T0" because "T0" sounds like "initial time" to me.

Just don't even think about requesting daylight savings time support.

[neilh10]

                 :) was there anything in there about DST :)

I was hinting we only have UTC...... get rid of local time offset !!!!! Just kidding.

But as a philosophy - all internal processing and external transfers reference is at UTC - only when it comes to a human readable interface would the Tz offset be added.
Are your good with a postfix of UTC and TZ ?

uint32_t Logger::getNowEpochUTC(void)
uint32_t Logger::getNowEpochTZ(void)
uint32_t Logger::getNowEpoch(void) {
    // Depreciated in 0.26.0, left in for compatibility
    return getNowEpochTZ();
}

    // Check the current RTC time
    uint32_t cur_logUTC = getNowEpochUTC();

[neilh10]

This was added to https://github.com/EnviroDIY/ModularSensors/releases/tag/v0.33.0 I forgot about this issue :) when I closed the associated PR #342.

It would be nice to be clear about what functionally can be accepted into the mainstream.

It seems to me that community contributions to EnviroDIY/ModularSensors are passively discouraged through lack of forums to discuss functionality/code priorities, and a method on how to prove the code is viable.

I really appreciate it takes effort to decide if functionality (code) PRs is in sufficient good state to be included, and how to be able to guarantee it works/tested if included. This is a standard challenge for all open source software, and especially a problem for embedded software that runs on small processors such as the mega1284.