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.
Los códigos y ejemplos proporcionados en WeAreCAS.eu son con fines educativos. Es imperativo no copiarlos y pegarlos ciegamente en sus entornos de producción. El mejor enfoque es comprender la lógica antes de aplicarla. Recomendamos encarecidamente probar estos scripts en un entorno de prueba (Sandbox/Dev). WeAreCAS no acepta ninguna responsabilidad por cualquier impacto o pérdida de datos en sus sistemas.
SAS y todos los demás nombres de productos o servicios de SAS Institute Inc. son marcas registradas o marcas comerciales de SAS Institute Inc. en los EE. UU. y otros países. ® indica registro en los EE. UU. WeAreCAS es un sitio comunitario independiente y no está afiliado a SAS Institute Inc.
Este sitio utiliza cookies técnicas y analíticas para mejorar su experiencia.
Saber más.