Rob writes: > The offset from UTC is not the kind of timezone information that is being > discussed here.
Sure it is. > It cannot be distributed via NTP anyway, as the server does not know > where the client is and thus cannot give it the offset info. True. > The interesting information is the DST schedule in use at the different > areas. That is part of the timezone data. > The client will have to know in which area it is and then can request the > timezone information for that area, which tells it what the offset is at > that specific moment. The client may very well need information on zones other than the one it is located in. It should check the nearest tzdata server for a standard tzdata file newer than the one it has and fetch it via a standard protocol from a well-known location on the nearest of a set of well-known servers. If it's an embedded system with minimal storage it can throw a way the stuff it doesn't need. We have a standard file. Ftp will do fine as a protocol. We just need to agree on a standard location for the current tzdata file and its timestamp and recruit a distributed set of servers. The NTP pool servers would do nicely. The client to periodically check for new tzdata files would be trivial. -- John Hasler j...@dhh.gt.org Dancing Horse Hill Elmwood, WI USA _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
