Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Batch job picking up wrong default date using SAP default date function

bruce_hartley
Active Participant
0 Kudos

First of all - ECC 5 system, not ECC 6

Second of all, system USED to be set up for the GMT time zone but isn't anymore

Third of all, a different ID runs this in batch than me but I don't have it's SU3 defaults but am trying to get them

Fourth of all, the system is now set to UTC-5 time zone as a default

Fifth of all, our BASIS person is in the UTC+1 zone

six of all, my defaults are UTC-5 time zone ( same as system )

I have a custom program that runs in batch.  One of the input parameters ( not a range - a parameter ) is a date field.  We set up a variant to feed the current date to the job using the "D - Dynamic Date Calculation" and asking it for the current date ( no offsets ).

The program stopped working awhile ago, and I couldn't for the life of me figure out why.  So the first thing I did was throw in some WRITE statements.  After I got that to production I took a look at the spool output and noticed that it's picking up the FOLLOWING day which is worthless because I don't want things that haven't happened yet.

The job is part of a multi-step job, so then I thought it might have gone over midnight so to speak - but according to SM37 in all instances, the step ran well before midnight, so that wasn't it.  It's not an hour off either, some steps ran before 11 PM and others ran after, so that's not it.  The first step in the job always runs at 19:30 EST and the 2nd step always runs right after it's done ( anywhere from 22:18 to 23:45 ).  In no case did it ever return the correct date, it's always the next day.

If I run the job as my user at the same time, it works.  Only when the job runs with this batch ID does it work differently.  As I mentioned above, I am in the process of obtaining for that user what their defaults are as maybe that is causing it.

My current theory is that in ECC 5 the system uses SY-DATLO for when it wants the date as opposed to SY-DATUM and that the special user is set up with their timezone in UTC-0 which would push it over the next day.  I can't schedule an earlier run because of the same reason I can't change the code easily.  I am also in the process of asking for FF access to do this should my BASIS team not be able to do so.

Has anyone ever been caught in this situation and/or seen it and dealt with it?

If you need more information don't hesitate to ask and I can try to get it

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Bruce,

Batch user's time zone( UTC+1) is 6 hours ahead of system's time zone(UTC-5).

Since your job is running around mid night system time, date on your batch user is actually next date.

Variant's dynamic date, which is current date, will be local date in user's time zone (will be sy-datlo and not sy-datum).

If you wish to continue with the same batch user, I guess a quick fix would be change dynamic date field to current date - 1 or change batch user time zone to system time zone. 

Hope it helps.

Thanks!

VM

2 REPLIES 2

Former Member
0 Kudos

Bruce,

Batch user's time zone( UTC+1) is 6 hours ahead of system's time zone(UTC-5).

Since your job is running around mid night system time, date on your batch user is actually next date.

Variant's dynamic date, which is current date, will be local date in user's time zone (will be sy-datlo and not sy-datum).

If you wish to continue with the same batch user, I guess a quick fix would be change dynamic date field to current date - 1 or change batch user time zone to system time zone. 

Hope it helps.

Thanks!

VM

bruce_hartley
Active Participant
0 Kudos

I want to amplify one very important point here - I made a bad assumption when I read the ECC 5 documentation because it documented the issue like the following in a code example:

PARAMETERS DATE LIKE SY-DATUM.

That line of code made me think it would use SY-DATUM.  As I have discovered and Venkat confirmed it, the system uses SY-DATLO instead.  For most of you, there won't be a difference as most sites do have a batch user and it's in the same time zone as the system.  However, when it's not, you can end up with the wrong date if you are not careful.  It makes sense now because if you set up jobs that run with different users you'd want the job to pick up ALL the attributes of that user including security rights, etc.

I would strongly suggest that SAP change the documentation on this as follows:

PARAMETERS DATE LIKE SY-DATLO.

I hope this helps anyone else who suddenly discovers there job is "back to the future" like mine was.