I am storing a time field in a timestamp without timezone column. The data is stored in UTC time. When I call the data back on heroku I get somehting like 2013-07-13T18:06:41.000Z which is what I want.
However, on my test machine, which is running windows 8 and postgres 9.3 I get this back Sat Jul 13 2013 18:06:41 GMT-0400 (Eastern Daylight Time). This is the right time sort of. It is the correct time with the offset to local time.
How can I match my production db to return the same or similar results to my test db?
It sounds like you want to run your test server with TimeZone set to UTC.
You can set this globally in postgresql.conf, or on a per-user, per-database, per-session or per-transaction basis.
See the manual.
Related
Is there any way to change SQL server datetime? GETDATE() and CURRENT_TIMESTAMP show the wrong dates.
I read that SQL reads the date from the server settings where the SQL instance is installed. But on this server(Windows SERVER 2019) time, date and timezone are correct.
Only in SQL Server are those settings wrong. I've tried to find a solution for this issue over internet but I couldn't find any.
Only SYSUTCDATETIME() shows correct information.
GETDATE() and CURRENT_TIMESTAMP will be working correctly. They return the server's local time. If the time is "wrong" then it's because the time on the server is "wrong"; most likely because it thinks it's in a different timezone to where it physically is or has the wrong DST setting.
Clearly, however, the time is correct on the server for its location (in the sense of that if it's observing CET it would display 11:38 around now) as you state that SYSUTCDATETIME() returns the correct UTC time.
if the server does have the wrong time setting, however, the fix is fix the time on the server. Speak to your server administrator about that. YOu change change the values GETDATE() and CURRENT_TIMESTAMP return as they are based on the host's time. This is why I am confident the time is correct, likely it is either set to the wrong timezone or DST setting as the UTC time is correct.
If, however, the time is correct for where the server is physically located, then the answer is don't use GETDATE() or CURRENT_TIMESTAMP to get the value for your local time, instead (like you have) use SYSUTCDATETIME() or SYSDATETIMEOFFSET() and then convert the time to your timezone in the application layer.
It seems the server timezone was changed since the SQL Server instance was started. Run the query below to verify the timezone SQL Server is currently using:
SELECT CURRENT_TIMEZONE();
If the result is different than the OS configuration, restart the SQL Server instance for the new timezone to become effective.
Our server is in CST timezone in the USA and CST timezone is 6 hours behind UTC timezone. Since it is daylight saving time, now the difference is 5 hours.
GETDATE function returns the correct local time, but GETUTCDATE returns a wrong UTC time. GETUTCDATE returns the time that is 7 hours (UTC+2:00) ahead of CST.
Checked the server's timezone and it is set to CST time zone (UTC - 6:00) and the option "Set timezone automatically" was off.
I am not sure what else to check for.
"Set time zone automatically" is a convenience added in Windows 10 / Server 2016. It uses available location information to set the time zone. It isn't necessary, and really shouldn't matter on a server. In fact, a best practice is to deliberately set servers to the UTC time zone, so that local time difference don't interfere. You may wish to consider that option.
However, there are a few things to check:
Is your server's clock synchronized to a reliable time source?
If your server is in a domain, then are the domain controller's clocks synchronized to an Internet-based time source or some other reliable time source?
If not in a domain, do you have "Set time automatically" or "Internet Time" turned on? Or some other mechanism for setting the clock correctly?
If not sure where the clock is synchronized, try w32tm /query /source from an elevated command prompt.
If you just want to check the raw UTC time, try [DateTime]::UtcNow from Powershell. (None of the time zone or DST settings will affect the result.)
If the system is configured for a local time zone, is "Adjust for daylight saving time automatically" (or "Automatically adjust clock for Daylight Saving Time" in the older control-panel setting) turned on? This setting should really never be disabled. It is there for legacy purposes only.
If not sure, try tzutil /g on a comand prompt. If the result has _dstoff in the name, then you should go turn it back on.
I want a C program to fetch the date time of centOS server from Ubuntu server via UDP. I wrote a code which is fetching UTC timestamp which is +06 hours from the actual date time in centOS. NTP is not allowed.
i used setsockopt, getsockopt, sendto & recvfrom for networking.
Port number 1099 & Centos timezone is CST, ubuntu timezone is UTC. Suppose, it is Fri, 28 Nov 2014 03:06:25 in Centos then ubuntu is recieving Fri, 28 Nov 2014 09:06:25 i.e. +0600 hrs. Format is UTC timestamp.
Is there any way to fetch the equivalent UTC timestamp of date time in centOS from ubuntu?
I am trying to sync date time of centOS & Ubuntu machine irrespective of timezone.
Please help! Any idea or suggestions.
Thanks.
I suppose CenOS CST is http://en.wikipedia.org/wiki/Central_Standard_Time (UTC-6). So Fri, 28 Nov 2014 03:06:25 CST is the same as Fri, 28 Nov 2014 09:06:25 UTC. So You are receiving correct UTC timestamp.
From the question it is unclear if You wrote server, which is sending timestamps or not.
Anyway, to convert timestamps look at:
gmtime() - interprests timestamp as UTC;
localtime() - interprets timestamp as local time (takes into account time zone)
tzset() - change timezone used by localtime() (and few other functions)
Also, if You need parsing of time in string representation, strptime() may help (just keep in mind zone names/meanings may be different or missing on different OSes).
I'm saving a date in a mysql db as datetime using UTC, so if cst time is 2014-07-22 10:34 am in the db it will save as 2014-07-22 15:34. When testing the app locally, osx 10.9, with either local db or connecting to remote db angular formats it correctly as 2014-07-22 10:34 am. When running the app on a server, ubuntu + nginx + sailsjs, the date reads as 2014-07-22 3:34 pm, so it's not taking into account the timezone. On the server I've set the correct timezone using tzconfig, and it shows local as cst and universal as utc. As I mentioned above, I can connect the local sails app to use the remote database and the time gets formatted correctly. So as long as the sails server is running locally the time is formatted correctly, but if I use the sails app on the server the time is incorrect. Any suggestions?
Thanks
I think your question needs a better explanation. It is hard to tell when exactly the date is messing up. Are you saying that when the sails server is moved to a remote server the date is wrong?
I know personally I stopped using date/time formats and make everything a unix timestamp (ie a NUMBER). This is universal and is never translated till I want it to be translated.
I use this in connection with moment.js (on the server and in angular) to translate my times to/from number and in the correct timezone.
This method has helped tremendously because dates can be manipulated by the server, the db or the client or the db adapter. Maybe none, maybe all and it might event be poor design on my part, but after switching to numbers, I never had these problems ever again.
Ok, I know I must be missing something, but my development server timestamp is off by 4 hours. I am running Mac OS X Leopard Server. The date command in a Terminal shows the correct time. I am in Eastern Standard Time (GMT -5). Is this a devserver setting?
In production google app engine runs in UTC time, so the dev server modifies the timezone to also run in UTC time (although I've seen a case where that doesn't work correctly).
Are you in Eastern Standard Time (GMT-5) or Eastern Daylight Time (GMT-4)?