DSXchange

Hi - I am trying to convert a date to Julian format. The format I require is

105202.

1 represents 21st century

05 is current year

202 is the days in Julian format.

Is there a fn or routine is DS to achieve this. Thank you.

Kumar

Hello Kumar,

the functions ICONV and OCONV will do this for you. I will split the actions into several lines, but it can be done in one line. You are not looking for a "Julian Date" but a specific date format - be careful of using misleading terms.

1. ICONV({Date},'D4/YMD[4,2,2]') Convert your displayable date into DataStage internal format, I'm using "2005/04/31" type format here.
2. INT(OCONV({1},'DY4')/100)-20+1 Gets the Century number offset by 20
3. OCONV({1},'DY4')[3,2] Gets the last 2 digits of a 4 digit year
4. OCONV({1},'DJ') Get the days-running in current year.

To remind you that the steps ArndW has provided can be further simplified to meet your requirement.

But I will be surprised to see even any IBM mainframe or financial organisation expecting date in that format as 05 in year will always represent 21st century....especially after the Y2k changes.

Sainath,

I intentionally broke up the command into it's separate components so that Kumar could see what and how ICONV/OCONV work. With that information he can write the command to his wishes. I prefer this over giving the actual answer to the question - thus the longer and more complex method than actually needed. But, what would you write? I would do it with 1 ICONV and 2 OCONVs in one line.

I completely agree with you.

As a Chinese proverb goes,

Give a person a fish and you feed him for today. Teach him finishing and he will feed himself for lifetime.

Also it is good for people who really have the requirement to find the answer than those who only need it for an interview.

By-the-way, I may have solved it with one IConv and one OConv.

Hi Sai,

Give a person a fish and you feed him for today. Teach him finishing and he will feed himself for lifetime.

That was a really great proverb and so apt for the situation, but there's a small typo "finishing"

Thank you Sai and ArndW

Kumar

Doh!! Correct proverb.

Give a person a fish and you feed him for today. Teach him fishing and he will feed himself for lifetime.

Your requirement will cause problems if you have dates ten years apart crossing a millenium boundary (for example 1005-07-29 and 2005-07-29). The "century" will be 1 in each case (11th and 21st). Your result will be identical in each case.

Sit a man by a fire and he's warm just for a while. Set him on fire and he's warm for life.

I think the requirement takes care of that as 2 digits are given for the year

CYYDDD

I disagree. There is no mention of given year in the requirement. Just the fact that there's a date. The requirement for a two digit year is in the output. My point was that one digit for the "century" may not be enough, or that the restriction on dates properly handled needs to be documented among the technical (design) metadata.

ray.wurlod wrote:Your requirement will cause problems if you have dates ten years apart crossing a millenium boundary (for example 1005-07-29 and 2005-07-29). The "century" will be 1 in each case (11th and 21st). Your result will be identical in each case.

Sit a man by a fire and he's warm just for a while. Set him on fire and he's warm for life.

I too had the same scenario, when i raised the same issue, i got very lethargic answer, their whole business were not there bofore 100. so they are not ready to forcast beyond 1000 years for current project:oops:

I do not think we will still be having the same systems in 1000 years from now. So there may not be the requirement to include 10 centuries in the date format.

I bet you don't even worry about the Y10K problem caused by having a four digit year either!

These date formats are commonly used, for example in Peoplesoft (oops, I mean Oracle), the format is yyyddd, where yyy is the number of years since 1900, and ddd is the day of the year. So today, August 2, 2005 is 105214.
For years before 1900, you are probably SOL.

Note that years before 2000 will result in a leading zero, that may disappear when the variable is evaluated in a numeric context.
So you have to be consistent, and be careful when doing comparisons:

String '098105' becomes number 98105, which becomes '98105' when converted back to a string, either implicitly or explicitly,
and '098105' != '98105'