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.
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.
Im developing an app thats hosted up in Azure. On my development machine when i edit and save dates (UK format - saving to local sql server 2012) theres no problem. When I deploy the same code base to Azure (same database structure & sql server version - db hosted in VM in Azure) Im getting an error
'the value 23/01/2014' is not valid for contract date
has anyone else experienced anything like this and could give me some pointers ?
Ive set the os on the VM machine to be uk region and the underlying dates in the tables both locally and remotely are exactly the same format. Is there anything obvious I could be missing ?
the value 23/01/2014' is not valid for contract date
Please run dbcc useroptions to check the language and dateformat. And by default, the date format for SQL server is in U.S. date format MM/DD/YY, unless a localized version of SQL Server has been installed.
You could try to use the international format YYYYMMDD for sending the datetime data to SQL Server or pass the date in date format being used on the SQL Server.
I have just had the task of moving an old ASP website / SQL DB to a new dedicated OVH server (French - all defaults set to US-Eng).
The DB has moved from SQL 2005 to SQL 2012 (web edition 64 bit).
I am having the old issue of date formats showing up as US format on the website e.g 8/3/2016 instead of 03/08/2016. This is even though in the database they are stored as ISO Date 2016-08-03 etc.
I enter the dates on the ASP Classic, website as UK format
e.g. 03/08/2016 and convert them to ISO format 2016-08-03 in the SQL that is passed to the Stored Procedure that has SET DATEFORMAT YMD at the top of it.
If I check the tables in the DB they are all stored correctly as ISO dates.
I have made sure all the SQL Logins to the DB have "British English" selected as their "Default Language".
If I view the database properties under options the Default Language is British English.
If I view the server properties under General->Language it's English (United States) but under Advanced->Default Language it's British English.
The dates are getting stored as ISO correctly as if I do a DATEDIFF(DAY,Stamp,GETDATE())=0 I can see all the records even though they are showing up on the website as US format 8/3/2016 (Why there are no zeros in front of US dates I don't know).
The ASP code hasn't changed or the DB code it was just ported into this new dedicated server and now I am getting these issues. I am sure I solved something like this ages ago just by changing the default login language but that doesn't seem to work on this box.
I am getting lots of Primary Key/Index errors due to duplicate insertions due to the dates (mixing up US/UK) from a .NET app I have that uses the Betfair API to get racing data e.g
EXEC dbo.usp_net_insert_betfair_market_selection #MarketID = 125932808, #SelectionID = 10593225, #Racedatetime = '2016-08-03 15:10:00', #MarketType = 'WIN', #HorseName = 'She Done Good';
Violation of PRIMARY KEY constraint 'PK_BETFAIR_MARKET_SELECTIONS'. Cannot insert duplicate key in object 'dbo.BETFAIR_MARKET_SELECTIONS'. The duplicate key value is (719859, WIN, Mar 8 2016 3:10PM).
However if I copy that EXEC statement and run it direct in a query analyser window it runs WITHOUT ANY ERROR.
I have been searching the web and I have seen someone suggest putting this code at the top of all ASP pages that show dates to force it show in UK format > https://www.webwiz.co.uk/kb/asp-tutorials/date-time-settings.htm
'* Set the server locale to UK
Session.LCID = 2057
This has worked on SOME pages but I have never had to do this before.
On pages with long lists of records and dates in one column I have wrapped the date in CONVERT(varchar, GETDATE(),103) in the SQL and it returns correctly on the page.
I am confused though as I have never had to do this on the old set up and it seems like there must be some setting that needs to change to fix all this on the new server (SQL and Web IIS 8) on same box.
I have tried going into the .NET Globalization for the site and changing Culture and UI Culture to English (en). However that didn't fix everything.
The "Language" preferences on the machine are set to English (UK) although I wouldn't have though that would have made a difference.
If I run this code in a query analyser either RD into the box, or through my local SQL console connected to the machine over the network
select name ,alias, dateformat
from syslanguages
where langid =
(select value from master..sysconfigures
where comment = 'default language')
In a query window (Remote Desktop into server) I get back
Name Alias dateformat
British British English dmy
Question
So it seems like something to do with the connection between the ASP website or .NET app and the server/database. Something I have missed or need to change as this all worked fine on the old WebServer -> Database Server setup we had.
Is there something I have overlooked to ensure dates are shown as UK on the website without editing every ASP page and SQL that contains dates as I never had to do that for the old setup.
Amazon recently announced support for time zone change in Oracle RDS.
Since this is still not supported for Microsoft SQL Server 2012, are there any workarounds, to obtain functionality similar to changing the whole database time zone?
Since you're asking for workarounds...
We basically totally disregard server time/database time zone and work entirely off of UTC. GetUtcDate() for instance for all 'DateCreated' columns. Since we've committed to that approach we just don't bump up against any issues.
If you need to store the time zone alongside your date data, you can use DateTimeOffset.
The one caveat is that maintenance plans will be run on server time. This has not been an issue because we normalize everything to local time (which is not UTC and not server time) in any of our calendaring programs.
I did this with MySQL on RDS by changing my instance DB Parameter Group to a custom one that I can edit the parameters for.
I then created the following procedure:
DELIMITER |
CREATE PROCEDURE mysql.init_connect_procedure ()
IF NOT(POSITION(‘rdsadmin#’ IN user()) = 1)
THEN SET SESSION time_zone = 'America/New_York';
END IF |
DELIMITER ;
Note: every other instruction on the internet uses the function current_user() instead of user() which did not work for me!
The catch to this configuration is that then you have to give privileges to all your database users to be able to execute this function, or they won't even be able to connect to the database, so for every user and every future user you have to run this command. (and no there is no wildcard access to procedures)
GRANT EXECUTE ON PROCEDURE mysql.init_connect_procedure TO 'user'#'%' ;
I edited the parameter init_connect for to be set as CALL mysql.init_connect_procedure . I am sure SQL SERVER has an equivalent parameter if not the same.
Restart the server and you should be good!
Warning: The user rdsadmin is the root user that only Amazon has the password to and uses to maintain and backup the database. You don't want to change the timezone for this user or you might damage your entire database. Hence the code to make sure it is not this user. I really recommend making sure the user is the same for SQL SERVER, this solution is only for MySQL and is a terrible solution, unfortunatly I had no other choice. If you can avoid doing this handle the timezone on your application end.
I understood from the GAE documentation that the production server timezone is always UTC. While developing locally, the server timezone is set to CET. Is there a way to force the local development server to also run on UTC ?
The development server is running on Mac OS.
Thanks,
Hugues
jut found the answer. In order to set the server timezone, just go in Eclipse, "Run configurations", then "VM arguments" and add the following "-Duser.timezone=UTC".
This will set the server timezone to the value you want (UTC) in this case. This is really handy as Google App Engine production will always run UTC whereas the development server (at least in my case) was running with local timezone. The net effect was that I had a different behavior between dev and prod.
Hugues
Well you can use this while saving a date value to your datastore to convert to your specific timezone.
DateFormat utcFormat = new SimpleDateFormat(patternString);
utcFormat.setTimeZone(TimeZone.getTimeZone("UTC"));
DateFormat indianFormat = new SimpleDateFormat(patternString);
utcFormat.setTimeZone(TimeZone.getTimeZone("Asia/Kolkata"));
Date timestamp = utcFormat.parse(inputString);
String output = indianFormat.format(timestamp);
GAE devServer uses local Timezone by default.
I use this code to force it to UTC:
boolean isDevEnvironment = SystemProperty.environment.value() == SystemProperty.Environment.Value.Development;
if (isDevEnvironment) {
TimeZone.setDefault(DateTimeZone.UTC.toTimeZone());
DateTimeZone.setDefault(DateTimeZone.UTC);
}
You need to run it once, in the very during server startup and initialization.