Suppose you have to deal with “legacy” things in the IOT (say ioLt …).
Most of the time these legacy things don’t have any kind of timezone management: they just store time in some timezone agnostic form, like [year, month, day, hour, minutes, seconds].
Moreover they don’t even have any kind of time sync with external sources (say NPT or whatever).
So:
1. you are required to syncronize time from your server to your things
2. you are required to manage timezones on behalf of your legacy things
Syncronize time from server to things
You decide the server has the right time and just want to send it to the things.
But … what timezone you choose to send?
And … what is the timezone of your server?
Are the all the things in the same timezone of the server?
Manage timezones on behalf of your legacy things
We can manage timezones in two different ways:
1. keep the timezone things-side and send to them the “localized” time
2. keep the timezone server-side and send to the things the UTC time
Which of the two depends mainly on the following: should your things show the time on some local display or not? If yes the thing should know the “localized” time, since it will have to make sense to the user who is expecting it in her timezone.
Hence, if the user contraints apply you have to follow method 1, otherwise method 2.
Of course in the absence of any other constraint, it turns out that method 2 is preferable, since time management will follow standard patterns of keeping centralized times in UTC.
Python and .Net API to generate localized datetime with respect to a given timezone
Ok, you have decided to follow method 1, and now you have to prepare server “current date”, localize it to the thing timezone and send it.
Here how to do it, supposing your timezone is ‘it’ or CET or ‘Europe/Rome’
Python
datetime.datetime.now(pytz.country_timezones['it'][0])
.Net
TimeZoneInfo.ConvertTimeFromUtc (DateTime.UtcNow, TimeZoneInfo.FindSystemTimeZoneById ("Europe/Rome"))
The main difference is that Pyhton datetime object is timezone agnostic by default, while .Net object cannot exist without a timezone. Hence with .Net we must start with the UTC time.
(credits:
https://flic.kr/p/4GSMuN
http://freestock.ca/skies_clouds_g61-angel_cloud__hdr_p2162.html)