we have a problem with local and utc timestamps.
So we have server communication done with UTC-timestamps but are using SMS configuration with local timestamps. Therefore we need to do time calculations (time, localtime) but with daylight saving.
Unfort the time.locatime() and time.gmtime() methods both give the same results - the utc time.time() method gives the system time, though set with utc+2.
What can we do here to get the correct behaviour ?
We have no ntp server.
Simply using +2 offset and overriding time.localtime() is not daylightsaving
You can’t set time zone from Python, but if you have a newer CPX4 firmware (I have 184.108.40.206 or 82001536_F2 from Feb-2010) and it has a time-zone setting under:
> Configuration > System > Date and Time Settings > Offset From UTC
The Digi does NOT handle daylight saving time, so you’ll need to manually fudge the time-zone as required.
However, telecom things can be tough as some send you UTC, some local time. It can even change without you moving if you roam to a new tower.
Time zone’s aren’t very complicated - they just create a constant which is 3600 * time-zone, which is added to the UTC.
Yes, it is a fixed offset. But the daylight saving is not recognized and so the offset may change from +2 to +1.
This change should be recognized. As I know the cpx4 does not do this.
Yes, and you can set a time offset in the cpx configuration, but if I call time.time() I got not the UTC time any more … in other words:
time.time(), time.localtime() and time.gmtime() all give the same results (utc + offset).
time.time() is the raw Real-Time-Clock hardware value, with for Digi would be what YOU set it to. If you enable cellular update, this is likely localtime. If you manually load UTC, then it is UTC. Time-zone has NO impact on RTC.
I have tested and seen that time.localtime() and time.gmtime() return different values. I have Python apps which (as example) need to upload data at 3pm based on localtime, etc.
I suspect the raw RTC clock value is your problem - I always disable cellular update as it is VERY unreliable. At most (perhaps 98%) of the sites it is good, but at the rest it is very, very bad (off by weeks or jumping about like crazy).
Unfortunately, the Digi SNTP support is also questionable. I find it either works well, or jumps around like crazy based on which NTP host you tie it too.
I do not see any difference in gmtime and localtime:
#> set time time=12:00 date=06.07.10 offset=2
offset (from UTC) 02:00
Current System Date and Time: Mon Jun 7 12:00:01 2010
Current UTC Date and Time: Mon Jun 7 10:00:01 2010
>>> print time.localtime()
(2010, 6, 7, 12, 0, 36, 0, 158, -1)
>>> print time.gmtime()
(2010, 6, 7, 12, 0, 46, 0, 158, -1)
I agree that there is a problem with time.localtime() and time.gmttime() returning the same value on the CX4. This is not an SNTP issue.
I am running the latest firmware (220.127.116.11 (Version 82001536_H1 10/15/2010) )