I have a very limited environment which have no standard linux/unix date/time API and have to synchronize clock against NTP server. I can communicate via UDP and get NTP reply. Now i need to convert NTP timestamp to the device date/time completly by myself.
I've found several ntp implementations (qntp, c#, java) but they all using system wide functions to convert NTP timestamp to the corresponding DateTime implementation.
Any avdice to how to convert or any links where i can read about such a conversion will be very appreciated.
Related
Wow! Tons of posts on converting GMT to local time, including correction for DST. But it seems my need is different.
As the title says, I have a stand-alone embedded system with no O/S. I'm using NTP to get UTC. That is used to tag events with an accurate date/time. I can correct UTC for the current time zone but cannot automatically adjust for DST.
Since there is no O/S, I don't have any of the Windows/Linux data such as time zone. So there is no way to locally adjust for the GMT offset.
It seems the only way for me to do this is to use an http call to find the offset, and the only way I can think of doing this is using the lon/lat or address. It would be possible for me to add lon/lat or address to the configuration so this seems like the only option.
I've seen references to sites which return the GMT offset based on location. Do these sites also automatically adjust for DST? To do that, they would have to use one of the solutions posted in many places in this forum, but that should be easy enough.
Thanks for the advice and help!
Dave
If you need to only convert a specific single timestamp to local time, then yes - you can use services such as those listed here. At least the ones offered by Microsoft and Google do convert a timestamp to the local time in the time zone given, in addition to providing the IANA time zone id.
Additionally, you'll find that the gettimezonebycoordinates function in the Microsoft Azure LBS Time Zone API returns a PosixTz value, such as "PST+8PDT,M3.2.0,M11.1.0". This is ideal for embedded systems, as you can set your TZ environment variable to this value and then many local APIs (such as with C, and others) will use this value in their conversions. This approach works best when you may be converting many different local time values and don't want to make an http call for each one.
Be aware, however, that using a POSIX time zone string has some limitations, such as being restricted to a single set of DST transition rules. They generally work ok for near-current time ranges, but not for historical purposes.
The time command on the redis-cli returns the current server time (doc here). How can I change the timezone on the redis server?
Note that redis gives me UTC timezone, whereas date on the Linux terminal shows me UTC+5, which is my correct timezone (Asia/Oral).
The time command is documented as using Unix time, which is UTC, so there's no way to change that. Timezone issues are complicated, so it makes sense for the Redis server not to concern itself with them.
Instead, convert it on the client using the libraries available on your platform.
I have a server in Usa and I have clients in different parts of the world, Australia, South america, Usa, Canada, Europe.
So I need to send notification of events one hour before the event take place.
So In sql server I have a table with different events those events are stored in Utc(2015-12-27 20:00:00.0000000). and in other table the timezone that belongs to every event ("Australia/Sydney").
So how could I calculate in a query when to send the notifications? or maybe I would have to do it with a server side language.
Could any one could help me with a possible solution.
Thanks
You've asked very broadly, so I can only answer with generalities. If you need a more specific answer, please edit your question to be more specific.
A few things to keep in mind:
Time zone conversions are best done in the application layer. Most server-side application platforms have time zone conversion functions, either natively or via libraries, or both.
If you must convert at the database layer (such as when using SSRS or SSAS, or complex stored procs, etc.) and you are using SQL Server, then there are two approaches to consider:
SQL Server 2016 CTP 3.1 adds native support for time zone conversions via the AT TIME ZONE statement. However, they work with Windows time zone identifiers, such as "AUS Eastern Standard Time", rather than IANA/Olson identifiers, such as the "Australia/Sydney" you specified.
You might use third-party support for time zones, such as my SQL Server Time Zone Support project, which does indeed support IANA/Olson time zone identifiers. There are other similar projects out there as well.
Regardless of whether you convert at the DB layer or at the application layer, the time zone of your server should be considered irrelevant. Always get the current time in UTC rather than local time. Always convert between UTC and a specific time zone. Never rely on the server's local time zone setting to be anything in particular. On many servers, the time zone is intentionally set to UTC, but you should not depend on that.
Nothing in your question indicates how you plan on doing scheduling or notifications, but that is actually the harder part. Specifically, scheduling events into the future should not be based on UTC, but rather on the event's specific time zone. More about this here.
You might consider finding a library for your application layer that will handle most of this for you, such as Quartz (Java) or Quartz.Net (.NET). There are probably similar solutions for other platforms.
You should read the large quantity of material already available on this subject here on Stack Overflow, including the timezone tag wiki and Daylight saving time and time zone best practices.
windows server has a registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation where the field ActiveTimeBias will return the offset in minutes from GMT for the machine that you are running on.
we have a web application that needs to present a user with their local time on an html page that we generate. we do this by having them set a preference for their timezone and then fetch the above value so that can compare server time and client time and do the correct calculation.
on servers that we have built this works great. we are deploying our application into a tier 1 cloud provider who is providing a windows server ami that we configure and use. what we have found is that when you use the clock control panel on a local server, the registry entrys for TimeZoneInformation are correct. when we do the same for this virtual machine, the entrys are correct with the exception of ActiveTimeBias.
Microsoft cautions against diddling the individual value in their usual fashion.
question for the community - has anyone else encountered this problem and if so, how did you fix it?
One usually doesn't program directly against these registry keys. For example, in .Net, we have the TimeZoneInfo class. It uses the same data, but in a much more developer-friendly way.
Regarding your particular question, the ActiveTimeBias key hold the current offset from UTC for the time zone that your server is set to. If your server is in a time zone that follows daylight savings rules, then this will change twice a year. If you manually update your time zone and refresh the registry, you will see it change.
The best advice I can offer is that since the timezone of the server is likely to be unimportant to anyone, you should set it to UTC.
See also: Daylight saving time and time zone best practices
I have a WCF Web-Service with a parameter of type DateTime. This Web-Service runs on Windows Azure. Our client is written in Java and run on a different time zone. When it calls this web-serve and passed a date-time (E.g. 2011-03-27 12:00+0100), the .NET Framework will automatically convert this date-time into the time zone of Windows Azure servers.
Is it possible to skip this conversion and get the exact time sent by the client?
This is the correct behaviour: in general it's best to work with co-ordinated universal time when working with distributed services. In your case Azure / WCF should report the time as 13:00, as the Azure clocks are set to UT.
Assuming that your Java client encodes dates in the proper way, then
Best practices for DateTime serialization in .NET 3.5
gives some hints on how to extract out the local date and time and the timezone information entered by the user. (Scroll to the bottom answer.)