Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Help needed in converting an int datatype to MM/DD/YYYY and converting another int to HH:MM PM Expand / Collapse
Author
Message
Posted Monday, August 27, 2012 1:18 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Today @ 9:27 AM
Points: 162, Visits: 1,037
When running the script below I noticed that the two result fields are of datatype int.
I would like to convert the value of the next_run_date to the format of MM/DD/YYYY and the value of next_run_time to the format of HH:MM AM or PM.

I have used
convert(DATE, CAST(dbo.sysjobschedules.next_run_date AS CHAR(12)), 103) AS Next_Run_Date,
in the script below but no matter what the value of the format (Ex: 100, 101, 102, or 103) I get the result of YYYY-MM-DD.

-- List Next Run Date And Time For All Jobs.
USE msdb
SELECT
sysjobs.name ,
dbo.sysjobschedules.next_run_date ,
dbo.sysjobschedules.next_run_time
FROM dbo.sysjobs
INNER JOIN dbo.sysjobschedules ON dbo.sysjobs.job_id = dbo.sysjobschedules.job_id
Order BY dbo.sysjobschedules.next_run_date, dbo.sysjobschedules.next_run_time asc

The result of the above script is:
name next_run_date next_run_time
syspolicy_purge_history 20120828 20000
Log_Backup 20120902 175500
Databases_Backup 20120902 180000
System_Databases_Backup 20120902 180500
database integrity check 20120902 181000
DBCC CheckDB 20120902 181500

I have the following script that appears to work correctly in converting an int to standard time format end with am or pm.

DECLARE @milTime INT
DECLARE @militaryTime INT
SET @militaryTime = 20000
SET @milTime = STUFF(@militaryTime / 100, 1, 0, REPLICATE('0', 6 - LEN(@militaryTime / 100)))
SELECT CASE ( ( @milTime / 100 ) % 12 )
WHEN 0 THEN '12'
ELSE CAST(( @milTime % 1200 ) / 100 AS VARCHAR(2))
END + ':' + RIGHT('0' + CAST(( @milTime % 100 ) AS VARCHAR(2)), 2)
+ CASE ( @milTime / 1200 )
WHEN 0 THEN ' am'
ELSE ' pm'
END

The result of the above query is
(No column name)
2:00 am

But when I include it in my original script the time showing am/pm does not apperar correctly.

SELECT
sysjobs.name ,
convert(DATE, CAST(dbo.sysjobschedules.next_run_date AS CHAR(12)), 101) AS Next_Run_Date,
dbo.sysjobschedules.next_run_time,

stuff(stuff(Right('0' + cast(dbo.sysjobschedules.next_run_time as varchar(6)),6),3,0,':'),6,0,':'),

STUFF(dbo.sysjobschedules.next_run_time / 100, 1, 0, REPLICATE('0', 6 - LEN(dbo.sysjobschedules.next_run_time / 100)))
+ CASE ( ( dbo.sysjobschedules.next_run_time / 100 ) % 12 )
WHEN 0 THEN '12'
ELSE CAST(( dbo.sysjobschedules.next_run_time % 1200 ) / 100 AS VARCHAR(2))
END + ':' + RIGHT('0' + CAST(( dbo.sysjobschedules.next_run_time % 100 ) AS VARCHAR(2)), 2)
+ CASE ( dbo.sysjobschedules.next_run_time / 1200 )
WHEN 0 THEN ' am'
ELSE ' pm'
END

FROM dbo.sysjobs
INNER JOIN dbo.sysjobschedules ON dbo.sysjobs.job_id = dbo.sysjobschedules.job_id
Order BY dbo.sysjobschedules.next_run_date, dbo.sysjobschedules.next_run_time ASC

This is the result from the above query:
name Next_Run_Date next_run_time (No column name)(No column name)
syspolicy_purge_history 2012-08-28 20000 02:00:00 0002008:00 pm
Log_Backup.Subplan_1 2012-09-02 175500 17:55:00 0017553:00 pm
Databases_Backup.Subplan_1 2012-09-02 180000 18:00:00 00180012:00 pm
System_Databases_Backup 2012-09-02 180500 18:05:00 0018055:00 pm
database integrity check 2012-09-02 181000 18:10:00 00181010:00 pm
DBCC CheckDB 2012-09-02 181500 18:15:00 0018153:00 pm

Any help will be greatly appreciated. I hope that I have not made this too confusing.

Thanks
Howard



Post #1350543
Posted Monday, August 27, 2012 1:21 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 2:39 PM
Points: 12,903, Visits: 32,143
if you convert to CHAR(12), most of the string gets truncated no matter the format.
try a CHAR(37) instead.


Lowell

--There is no spoon, and there's no default ORDER BY in sql server either.
Actually, Common Sense is so rare, it should be considered a Superpower. --my son
Post #1350546
Posted Monday, August 27, 2012 1:29 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Today @ 9:27 AM
Points: 162, Visits: 1,037
Lowell:

Thank you for the fast reply.

The only Char(12) that I see is on the following line in the script.
convert(DATE, CAST(dbo.sysjobschedules.next_run_date AS CHAR(12)), 101) AS Next_Run_Date,
I changed this Char(12) to Char(37) and the formatting of the next_run_date did not change.
Also, this won't help me formatting the next_run_time.

Would you please clarify what you mean?

Thank you,

Howard



Post #1350548
Posted Monday, August 27, 2012 2:09 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 2:39 PM
Points: 12,903, Visits: 32,143
ok, this gets you your value as datetime, right? i guess you could manipulate it a bit more if you really wanted AMPM in it, but i would want the datetime value myself.
/*
--Results
name NextRunDate
syspolicy_purge_history 2012-08-28 02:00:00.000
Email Reminders 2012-08-28 07:00:00.000
Last EDI Exported Status 2012-09-02 09:00:00.000
*/
SELECT
sysjobs.name ,
CONVERT(datetime,
STUFF(STUFF(CONVERT(VARCHAR,dbo.sysjobschedules.next_run_date),7,0,'-'),5,0,'-')
+ ' '
+ stuff(stuff(Right('0' + cast(dbo.sysjobschedules.next_run_time as varchar(6)),6),3,0,':'),6,0,':')
) AS NextRunDate
FROM dbo.sysjobs
INNER JOIN dbo.sysjobschedules ON dbo.sysjobs.job_id = dbo.sysjobschedules.job_id
Order BY dbo.sysjobschedules.next_run_date, dbo.sysjobschedules.next_run_time ASC



Lowell

--There is no spoon, and there's no default ORDER BY in sql server either.
Actually, Common Sense is so rare, it should be considered a Superpower. --my son
Post #1350569
Posted Monday, August 27, 2012 2:30 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Friday, June 27, 2014 12:43 PM
Points: 13,872, Visits: 9,596
When you return a date (or datetime, etc.) datatype in a query in Management Studio, the format you get is YYYY-MM-DD. Has nothing to do with how the data is stored, has to do with how SSMS displays it. That's a presentation layer issue.

If you want to convert to Date datatype in the query, then you'll get YYYY-MM-DD in Management Studio, no matter what format you specify in the conversion from character data.

Unless the end users will be using SSMS as their application (doubtful), this doesn't actually matter, since their actual application can apply formatting in the presentation layer, where it belongs.

If you need it to be formatted in SSMS, then convert it to a string (varchar) and use the appropriate mask in the Convert statement. But make sure the final value is a string, not a Date/DateTime. You won't be able to use any of the T-SQL date-math functions on that, and will have issues with Order By, etc., since it'll be a string, not a date, but that's the tradeoff on that kind of thing.


- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Post #1350585
Posted Monday, August 27, 2012 2:44 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Today @ 9:27 AM
Points: 162, Visits: 1,037
Lowell:

Thank you for the revised script.

However, I was trying to return the two separate columns.

The next_run_date as MM/DD/YYYY

and the next_run_time as HH:MM AM/PM.

GSuared:

Thank you for the explanation.

Howard



Post #1350593
Posted Tuesday, August 28, 2012 9:37 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Today @ 9:27 AM
Points: 162, Visits: 1,037
I finally figured out the solution.

-- List Jobs Next Run Date and Time.
-- Format Next_Run_Date MMM DD, YYYY and Next_Run_Time HH:MM AM/PM.
SELECT
sysjobs.name ,
CONVERT( varchar,cast(cast(dbo.sysjobschedules.next_run_date as char(8)) as date),107) AS NextRunDate,
CASE WHEN dbo.sysjobschedules.next_run_time < 120000
THEN ISNULL(LEFT(CONVERT(VARCHAR, CONVERT(DECIMAL, dbo.sysjobschedules.next_run_time)
/ 10000), 4) + ' AM', 'None')
ELSE ISNULL(LEFT(CONVERT(VARCHAR, CONVERT(DECIMAL, dbo.sysjobschedules.next_run_time)
/ 10000 - 12), 4) + ' PM', 'None')
END JOB_start_time
FROM dbo.sysjobs
INNER JOIN dbo.sysjobschedules ON dbo.sysjobs.job_id = dbo.sysjobschedules.job_id
Order BY dbo.sysjobschedules.next_run_date, dbo.sysjobschedules.next_run_time ASC

Thanks to everyone for their help.

Howard



Post #1351056
Posted Wednesday, August 29, 2012 3:32 PM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 4:00 PM
Points: 1,945, Visits: 3,024
>> When running the script below I noticed that the two result fields [sic: columns are not fields] are of data type INTEGER. I would like to convert the value of the next_run_date to the format of MM/DD/YYYY and the value of next_run_time to the format of HH:MM AM or PM.<<

Your problem is that you have no idea how RDBMS and SQL work. We have abstract data type in SQL; how they are stored in the databases has nothing whatsoever to do with how they are displayed in the presentation layers.

Furthermore, the only display format allowed in ANSI/ISO Standard is 'YYYY-MM-DD HH:MM:SS.SSS', not the local dialect you think you should have. That was how COBOL worked in the 1950's when there were no temporal data types. All temporal stuff has to be done with procedural code and strings. Just like you are doing now! You also used context sensitive COBOL field names instead of ISO-11179 data element names.

We have a timestamps data type, which MS calls DATETIME2(n), so you should not split out the DATE and TIME fields (yes, this is the only place ANSI used 'field'; parts of temporal values).

These are huge conceptual error and not a little mistake. Let's make guesses and see if we can re-write this pseudo-COBOL to SQL.

SELECT J.name, JS.run_timestamp
FROM DBO.SysJobSchedules AS JS, DBO.SysJobs AS J
WHERE J.job_id = JS.job_id;

>> I have the following script that appears to work correctly in converting an INTEGER to standard time format end with am or pm. <<

This is a stinking kludge and should not exist. Standard time does not have the old AM/PM. This will improve the quality of data in your enterprise by orders of magnitude.

Now, create two look up tables, load the dates with 50, 10 or whatever years, load the times with a full day. Do the look ups and then add the date and time together.

Create TABLE Stupid_Integer_Dates
(cal_date DATE NOT NULL,
int_date INTEGER NOT NULL PRIMARY KEY);

Create TABLE Stupid_Integer_Times
(cal_time TIME NOT NULL,
int_time INTEGER NOT NULL PRIMARY KEY);

Finally, find the moron that put a timestamp in integers and kill him. I suggest burning him at the stake with his COBOL manuals


Books in Celko Series for Morgan-Kaufmann Publishing
Analytics and OLAP in SQL
Data and Databases: Concepts in Practice
Data, Measurements and Standards in SQL
SQL for Smarties
SQL Programming Style
SQL Puzzles and Answers
Thinking in Sets
Trees and Hierarchies in SQL
Post #1351937
Posted Wednesday, August 29, 2012 3:35 PM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 3:53 PM
Points: 20,705, Visits: 32,352
CELKO (8/29/2012)
>> When running the script below I noticed that the two result fields [sic: columns are not fields] are of data type INTEGER. I would like to convert the value of the next_run_date to the format of MM/DD/YYYY and the value of next_run_time to the format of HH:MM AM or PM.<<

Your problem is that you have no idea how RDBMS and SQL work. We have abstract data type in SQL; how they are stored in the databases has nothing whatsoever to do with how they are displayed in the presentation layers.

Furthermore, the only display format allowed in ANSI/ISO Standard is 'YYYY-MM-DD HH:MM:SS.SSS', not the local dialect you think you should have. That was how COBOL worked in the 1950's when there were no temporal data types. All temporal stuff has to be done with procedural code and strings. Just like you are doing now! You also used context sensitive COBOL field names instead of ISO-11179 data element names.

We have a timestamps data type, which MS calls DATETIME2(n), so you should not split out the DATE and TIME fields (yes, this is the only place ANSI used 'field'; parts of temporal values).

These are huge conceptual error and not a little mistake. Let's make guesses and see if we can re-write this pseudo-COBOL to SQL.

SELECT J.name, JS.run_timestamp
FROM DBO.SysJobSchedules AS JS, DBO.SysJobs AS J
WHERE J.job_id = JS.job_id;

>> I have the following script that appears to work correctly in converting an INTEGER to standard time format end with am or pm. <<

This is a stinking kludge and should not exist. Standard time does not have the old AM/PM. This will improve the quality of data in your enterprise by orders of magnitude.

Now, create two look up tables, load the dates with 50, 10 or whatever years, load the times with a full day. Do the look ups and then add the date and time together.

Create TABLE Stupid_Integer_Dates
(cal_date DATE NOT NULL,
int_date INTEGER NOT NULL PRIMARY KEY);

Create TABLE Stupid_Integer_Times
(cal_time TIME NOT NULL,
int_time INTEGER NOT NULL PRIMARY KEY);

Finally, find the moron that put a timestamp in integers and kill him. I suggest burning him at the stake with his COBOL manuals


Chill on the threats and name calling please. And the smiley at the end doesn't change the lack of professionalism demonstrated.



Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Post #1351939
Posted Wednesday, August 29, 2012 6:49 PM
SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Tuesday, September 23, 2014 8:31 AM
Points: 4,358, Visits: 9,537
CELKO (8/29/2012)
>> When running the script below I noticed that the two result fields [sic: columns are not fields] are of data type INTEGER. I would like to convert the value of the next_run_date to the format of MM/DD/YYYY and the value of next_run_time to the format of HH:MM AM or PM.<<

Your problem is that you have no idea how RDBMS and SQL work. We have abstract data type in SQL; how they are stored in the databases has nothing whatsoever to do with how they are displayed in the presentation layers.

Furthermore, the only display format allowed in ANSI/ISO Standard is 'YYYY-MM-DD HH:MM:SS.SSS', not the local dialect you think you should have. That was how COBOL worked in the 1950's when there were no temporal data types. All temporal stuff has to be done with procedural code and strings. Just like you are doing now! You also used context sensitive COBOL field names instead of ISO-11179 data element names.

We have a timestamps data type, which MS calls DATETIME2(n), so you should not split out the DATE and TIME fields (yes, this is the only place ANSI used 'field'; parts of temporal values).

These are huge conceptual error and not a little mistake. Let's make guesses and see if we can re-write this pseudo-COBOL to SQL.

SELECT J.name, JS.run_timestamp
FROM DBO.SysJobSchedules AS JS, DBO.SysJobs AS J
WHERE J.job_id = JS.job_id;

>> I have the following script that appears to work correctly in converting an INTEGER to standard time format end with am or pm. <<

This is a stinking kludge and should not exist. Standard time does not have the old AM/PM. This will improve the quality of data in your enterprise by orders of magnitude.

Now, create two look up tables, load the dates with 50, 10 or whatever years, load the times with a full day. Do the look ups and then add the date and time together.

Create TABLE Stupid_Integer_Dates
(cal_date DATE NOT NULL,
int_date INTEGER NOT NULL PRIMARY KEY);

Create TABLE Stupid_Integer_Times
(cal_time TIME NOT NULL,
int_time INTEGER NOT NULL PRIMARY KEY);

Finally, find the moron that put a timestamp in integers and kill him. I suggest burning him at the stake with his COBOL manuals


These tables are built in MSDB and are populated by SQL Server agent. I would bet you anything this has been around and setup this way as long as SQL Server has had an agent available.

No matter how much we want to follow standards, there are just times when you have to deal with stupidity and get over it. Ranting on the OP in this case is useless - since he has no choice and no way to make any of the changes you recommend.


Jeffrey Williams
Problems are opportunites brilliantly disguised as insurmountable obstacles.

How to post questions to get better answers faster
Managing Transaction Logs
Post #1351971
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse