compileTime() wrong TZ about eztime

[ropg]

Ah, in that case, try dateTime(compileTime() - ( yourTZ.getOffset() * 60 ) ), that might correct compileTime expressed in the time of a timezone.

[ropg]

Compile time is not stored with a timezone, so ezTime cannot know. So it assumes that compileTime is UTC. Can you try MyTz.setTime(compileTime()) and then just dateTime()?

[mike-s123]

Thanks, that works to properly display the compile time, but it's not clear how to get back to the correct time after...

Timezone myTz;
myTz.setPosix("EST5EDT,M3.2.0,M11.1.0");
 { time_t timeHold;
   unsigned long milliHold;
   Timezone UTC;
   if ( queryNTP("192.168.168.1", timeHold, milliHold)) { 
     myTz.setTime(compileTime());
   } 
   response_message = dateTime(RFC850);
   UTC.setTime(timeHold);
 }

so far, so good. But since setTime only takes full seconds, each pass could cause up to a 1 second error when restoring the proper time.

I settled on just using
dateTime(compileTime(),"l, d-M-y G:i:s ~U~T~C"));
, which I think is still going to bounce around by an hour with summertime changes.

[ropg]

I have no idea what you're trying to do there. If you have an NTP server, then why on earth would you use compileTime? compileTime, in my view, is not really useful for more than impressing your friends if you have no internet and want to show an Arduino displaying something like the proper time, it is nothing more than the static time the binary was compiled, after all.

[mike-s123]

I'm using this on an ESP8266 based project. On an informational web page, we show info about the state, sketch size, free heap, code version, etc. I added compileTime to that, so I'm using it for what it actually is (or should be) instead of DATE and TIME, where I have no control over format.