This article explains how to keep an underlying numeric variable (for calculations) while forcing its display in a date format.
The Problem: Storage vs. Display
You want to create a table where the date is stored as a number (to allow for future sorting and calculations) but is displayed as a readable date (16JUL2023).
/* 1. Création via FedSQL */
proc fedsql;
create table work.ma_table as
select datepart(timestamp_col) as ma_date
from source;
quit;
/* 2. Modification des métadonnées via PROC DATASETS */
proc datasets lib=work nolist;
modify ma_table;
format ma_date date9.;
quit;
run;
1
/* 1. Création via FedSQL */
2
PROC FEDSQL;
3
create TABLE work.ma_table as
4
select datepart(timestamp_col) as ma_date
5
from SOURCE;
6
QUIT;
7
8
/* 2. Modification des métadonnées via PROC DATASETS */
9
PROC DATASETS lib=work nolist;
10
modify ma_table;
11
FORMAT ma_date date9.;
12
QUIT;
13
RUN;
Beware of the "Good Idea That Isn't": The PUT Function
It's tempting to solve the problem directly in the SQL by converting the data:
/* À ÉVITER si vous voulez garder du numérique */
SELECT PUT(ma_date, date9.) as ma_date_str ...
1
/* À ÉVITER si vous voulez garder du numérique */
2
SELECT PUT(ma_date, date9.) as ma_date_str ...
Why is this dangerous? The PUT function transforms your date into a character string (VARCHAR).
You lose the ability to sort chronologically (the sort will become alphabetical: "01FEB..." will come before "01JAN...").
You lose the ability to perform date calculations (adding days, calculating differences).
The Special Case of Implicit Functions
Note that in some contexts, FedSQL is "intelligent". If you use a function that explicitly returns a date type (like DATEPART on a timestamp), FedSQL can sometimes automatically assign a default format to the resulting column. However, for precise control (e.g., preferring DDMMYY10. to DATE9.), post-processing methods (CASUTIL or DATASETS) remain the only reliable guarantees.
The codes and examples provided on WeAreCAS.eu are for educational purposes. It is imperative not to blindly copy-paste them into your production environments. The best approach is to understand the logic before applying it. We strongly recommend testing these scripts in a test environment (Sandbox/Dev). WeAreCAS accepts no responsibility for any impact or data loss on your systems.
SAS and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS Institute Inc. in the USA and other countries. ® indicates USA registration. WeAreCAS is an independent community site and is not affiliated with SAS Institute Inc.
This site uses technical and analytical cookies to improve your experience.
Read more.