I am building a tool which displays Skype persistent chat information along with participants information. For one of the requirement, I need to filter the tblComplianceParticipant table in a given date range.
I tried many different approaches to convert tblComplianceParticipant.joinedAt column to human-readable format like 'yyyy-mm-dd', etc. but no luck so far. Data in this column are 18 digit numbers, starting with "63" for example 636572952018269911 and 636455769656388453.
These values are also not in 'windows file time' format because https://www.epochconverter.com/ldap gives the future dates with above values.
I tried looking at #JonSkeet's answer on 18 digit timestamp to Local Time but that is c# specific. I tried to replicate similar logic in SQL but no luck.
Is there any way to convert this 18 digit numbers to normal date format and perform where clause on it?
Online converter which gives desired output: https://www.venea.net/web/net_ticks_datetime_converter#net_ticks_to_date_time_and_unix_timestamp_conversion
However, I was looking for underlying logic to convert it myself as I need to perform where clause on it in SQL server stored procedure.
Our Skype administrator provided me with a SQL function (fnDateToTicks) which was part of Skype database (mgc) (Earlier, I didn't have permission so could not see it). I am verifying with him whether it is an internal IP or standard solution by Microsoft so I can share it with the larger community.
The only thing i can think is worth trying:
select CAST ([Timestamp Column] as datetime)
Which will format it as yyyy-mm-dd 00:00:00:000
This may work for SQL Server 2008 and onwards
Related
We're working on a IOS app using Microsoft's Azure Mobile Services. The web GUI creates date-time as DateTimeOffset fields, which is fine. But when we have the mobile put datetimes into the database, then read them from the database, via Entity Framework, we're seeing them adjusted to UCT. (We see the same thing when we view the records in SSMS.)
I've always been frustrated by the lack of timezone support, in SQL's standard datetime types, and I'd thought that DateTimeOffset would be better. But if I wanted my times in UTC, I'd have stored them in UTC. If a user enters a time as 3:00 AM, CST, I want to know he entered CST. It makes as little sense to me to convert it to UTC, and throw away the offset, as it did to assume that 3:00 AM CST and 3:00 AM PDT were the same.
Is there some kind of database configuration I can do to keep the Azure database from storing the dates in UTC?
The issue is that at some point in Azure Mobile Services, the property is converted to a JavaScript Date object, which cannot not retain the offset.
There are a couple of blog posts describing this issue, and possible workarounds:
https://blogs.msdn.microsoft.com/carlosfigueira/2013/05/13/preserving-date-time-offsets-in-azure-mobile-services/
http://michele-colombo.it/2014/11/azure-mobileservices-how-to-properly-save-datetimeoffset-with-offset/
Essentially, they both take the same approach of splitting out the offset into a separate field. However, looking closely at these, they both make a crucial mistake:
dto.DateTime.ToUniversalTime()
Should actually be:
dto.UtcDateTime
The DateTime of a DateTimeOffset will always have DateTimeKind.Unspecified, and thus ToUniversalTime will assume the source is local, rather than using the offset of the DTO.
There are a few other similar errors I see in the code in these posts, so be careful to test thoroughly. However, the general approach is sound.
We're using a Node.js backend and noticed the same thing with DATETIMEOFFSETs read from our SQL Server database being returned in UTC regardless of the offset. Another alternative is to convert the DATETIMEOFFSET at the query-level so that it is outputted as a string with the timezone information. The following converts a DATETIMEOFFSET(0) field to the ISO8601 format; however, other possible styles can be used as documented here:
SELECT CONVERT(VARCHAR(33), [StartDate], 126) AS [StartDate] FROM [Products];
The new output is now: "2016-05-26T00:00:00-06:00" instead of "2016-05-26T06:00:00+00:00"
Of course, this means that the client must serialize the string into their respective format. In iOS, the ISO8601 library can be used to read the output as either a NSDateComponents or NSDate.
One benefit of this approach is that any database-level checks or triggers can do date comparisons using the DATETIMEOFFSET instead of trying to take into account a separate offset column with a basic DATETIME.
I have recently starter working with sql server instead of mysql.
I have a time column which I've noticed stores time as such: hh:mm:ss:nnnnnnn
Thing is I only want to to store hh:mm:ss, and I can't seem to figure out how to do that.
I do apologize if this is really obvious, I have had a long day and my searches did not return anything that helped.
time has a precision parameter which is "fractional second precision" so if you need hh:mm:ss you have to use time(0) as datatype
use the Time datatype which is available since 2008 onwards
If on SQL 2008, use the time datatype, and just store the hh:mm:ss; the nanoseconds will be 0. Just display the value back in the desired format in your presentation layer.
If on SQL 2005 (or older), you'll need to store the data as a datetime, and input the date version as some constant (usually 1900-01-01). Again, format the data at the presentation layer, not at the database.
I have the following query in MS Access and needs to be converted to SQL Server. I am trying to understand what does the format function do here and what is the use of "0".
SELECT Format([SumOfTotalPopulation],"0") AS Expr1 , SumOfTotalPopulation FROM
qry_ASSET_STREAM_DS_POP_PROP ;
Can anyone help me understad this. The above code is present in MS Access 2003 and Im working on SQL Server 2008 R2.
In your case, Format([SumOfTotalPopulation],"0") just removes the decimals from the number.
In SQL Server, you could use something like Str(sumOfTotalPopulation,12,0)
Or you could use Round()
The Access Format() function behaves differently based on the data type passed into it. In this example, I'm assuming that your SumOfTotalPopulation field is a number, which means that the formatting will be done as described here - basically, it will be formatted as an integer - no decimal point, no thousands separator.
The good news for you is that if the field in SQL Server is already defined as an integer type, you won't have to do this formatting. Otherwise, you should be doing this formatting at the presentation layer (user interface, web page, report, etc.) and not in the query itself.
Access teaches a lot of bad habits. Rather than translate what you have in Access one-for-one, take this opportunity to update things to be done "the SQL Server way" wherever possible.
I’m having a problem with a linked Informix table in MS SQL Server 2008r2. When I query this table, it seems to ignore some of the criteria I’m passing to it but not others. For example if I put a condition on the rowdate field the remote query part of the execution plan does not show any WHERE clause but if I put criteria on another field such as ACD it does show.
It seems it does not pass any criteria on the rowdate field but does on all others.
I know the field is indexed on the Informix side. If it helps the table I’m linking is from Avaya CMS and it is linked via the OpenLink ODBC driver.
EDIT:
As far as I know it is Informix Dynamic Server 2000 and it is on Solaris. The column comes up as a DATE data type which is correct. I have tried passing the criteria as ‘2010-08-03 00:00:00’, ‘2010-08-03’, CONVERT(date,’2010-08-03’) and a few more variations. When the data is returned to SQL server it is in the format yyyy-mm-dd.
When I view the execution plan I can see the remote query with all the other criteria followed by a filter for only the rowdate field.
I know that rowdate is indexed and that the driver does normally communicate that information as we use it in other applications (Business objects and MS Access) and they don’t have a problem
I managed to figure it out but it is the strangest thing ever. I went down the route of passing the date in different formats. My default is to use the normal YYYY-MM-DD that of course did not work so I tried YYYY-MMM-DD, still nothing. After going through LOTS of combinations I found one that works Mmm-DD-YY and it has to be exactly that! SEP-21-2010 wont work but Sep-21-2010.
I wonder if this is just a strange hang up from Informix or something in the driver, anyway it works.
On a side note has anyone noticed how strange it is that people from the America write the date month, day year? Stop and think about it for a second, do you say the number 2410 as “Four hundred, ten, two thousand”? The best part about it is try asking yourself this, what day is American independence day? Most Americans say “That’s easy you limey person it is the 4th of July” hmmmm day month (year), the only date they say round the right way is the date they got their independence. I will leave it up to the SO community to see the irony in that
Example query below:
select *
from OPENQUERY (AVAYA, 'select row_date,starttime,intrvl,acd from root.hagent where
row_date = ''NOV-22-2012'' and acd = 1 and split = 1 and starttime = 1900')
By the way I managed to extract accurate data via both MMM-DD-YYYY and Mmm-DD-YYYY.
We have a problem affecting the production environment only.
We have a VB6/ASP website that allows for data in a database table to be hand edited.
It looks alot like an editable datagrid.
One of the editable columns is a date and when the record is saved dates day/month are being reversed.
03/11/2008 becomes 11/03/2008, if you were to resave the record the date is again 03/11/2008.
I have checked the DB value and it is indeed being reversed however the same identical code on the test systems does not do this.
So i'm very confident i'm looking for an environment change. The test system has the DB and Site hosted locally and in the live setup we have a separate web site server and database server. Where do you suggest I start looking for this problem. I've checked the regional settings on the servers and they are set to United Kingdom and the OS date format is correct.
This is SQL Server 2000. hit me with some ideas!.
Thanks :)
If you convert the user supplied string to a date before you feed it to the DB, then the Session.LCID of the thread executing your ASP page is responsible for how dates are interpreted.
If you feed the date as a string to SQL Server and let the conversion happen there, it will be useful to look into the SET DATEFORMAT and the SET LANGUAGE statements.
So here is my idea: Either stop using (encouraging your users to use) ambiguous date formats, and this problem will disappear, or make sure all links of the processing chain have a clear understanding on what format to expect.
This is almost certainly to do with either your machine or the db server being set to US date format. Double check both the system settings.
Alternatively, a quick Google search will bring up a few options for manipulating the data so it will do what you need.
How about the regional settings of the OS?
The following
select name ,alias, dateformat
from syslanguages
where langid =
(select value from master..sysconfigures
where comment = 'default language')
Returns the same result on test and live
us_english English mdy
The problem is the system cannot be redeployed to changed. I need to identify the cause and fix it.
Go into regedit and go to the following location in the Windows Registry:
HKEY_USERS.DEFAULT\Control Panel\International\
Check to make sure that the "sShortDate" field is correct.
The short date format stored in this location many times is different then the short date format stored in the Windows Control Panel/Regional Options. The short date in the regional options is for the user that you are logged into Windows as. The "sShortDate" field in HKEY_USERS in the short date format used by the Windows Services.