nelson ostos wrote on 26th May 2002 12:17:
HI

The session tt5100m000 (Maintain Job Data) show me in the forms field: Next Execution Date, the value 2002/05/26 16:00.
When I use GTM, the table ttaad500 have the the values
2002/05/26 in the fields ttaad500.edte and 2100 in the ttaad500.stim.
Could you explain me how Baan show the value 16:00 and store the value 2100?

Thanks

Something wrong you can see "1600" in ttaad500.stim !

Hi Vamsi,

I checked on our system, I couldnt find the field, ttaad500.stim in the tools table ttaad500

I think this might be an older version of BaaN where the, edte might be a date field and stim might be a long/integer field.

There are some of the fields, which shows 2100 etc as in the time field but are stored a plain numbers than UTC/date formats. For example, the Role authorizations sessions, tables like ttams333 etc.

I didnt quite get your statement clear -
"Could you explain me how Baan show the value 16:00 and store the value 2100?"

I think it might be dependent on the user data template the time zone can be specified.

Hi,
I think all date and time fields are converted to GMT when they are saved in Oracle database. Technically the form and GTM should show same values as they are already converted to locale of user. If the table is viewed at Database (especially Oracle) level, one should consider above fact.

regards
ravi

Hi guys -
Nelson is working on 4c something. The date and time fields are stored separately in 4c.

I looked into the table ttaad500 (the Job Management Table), and I found on our system the same problem. The table ttaad500 shows 1600, and the maintain jobs sesssion (ttaad5100m000) shows 21:00. Why would this be? It is not a system wide/time problem. Hours Accounting table (tihra100) shows the same time as the Maintain Hours Accounting (tihra1101m000) session shows. What is special about the Job table, or the Job session? Unfortuantely, they are "ttaad" components, so I can't see if they do anything in the script, or even if they use the normal 'time' domain in the table.

Anyone familiar with Job Management able to help out on this one? There is a calendar field on that table that we don't have filled out on our system (we are only a test system) - could that be effecting things?

Hi Lisa, Ravi,

The dates/times are stored in dates formats if the table fields use date/time/utc domains and not if they are stored as long as in the case of ttams333. In that case, 2400 or 2100 are interpreted as 24 hrs = 12 am/pm or 2100 = 11pm.

This is just my observation... :rolleyes:

The dates/times are stored in dates formats if the table fields use date/time/utc domains and not if they are stored as long as in the case of ttams333. In that case, 2400 or 2100 are interpreted as 24 hrs = 12 am/pm or 2100 = 11pm.

Hmm... 2100 = 11 pm ... I am thoroughly confused guys!

Um, yea, Vamsi, I'm with you. 2100 = 9pm, not 11pm.

Not a UTC problem, this is Baan IV - unless they changed that field to the newly backported utc format, and it's not working right yet?? Not a time zone problem, the time shown on the table would still be the same as in the session, just not what is expected. Not a system time problem, the table tihra100 shows the same time as the session. It's not showing seconds since midnight (you might see this on some tables instead of the interpreted time), because 1600 would be a much lower time than 11:00.

My vote goes to UTC format that is not yet working properly. I can't prove it unless I see the table def and/or the script - anyone at Baan reading?? hehe

Also, Nelson - can you tell us which time was correct? The table time or the session time?

sorry, my mistake ... with numbers

seems I am successful in confusing Vamsi... :p

Here are the screen shots for the examples I have been referring to...

To answer to Lisa's issue -


Unfortuantely, they are "ttaad" components, so I can't see if they do anything in the script, or even if they use the normal 'time' domain in the table.


Please refer to the attached document -

Me have nothing to contribute on the subject :(. Me have no access to Baan IV. Me leave it to the experts. Me go to Mervyns.

OK, NP, I found the field domain = tttime (in table ttaad421 = tables table)
Not much help though. The domain says it is very similar to the tctmhs domain, used in hours accounting. It should be showing the same way. Must be something going on in the script?

well, Lisa, I am on the latest BaaN-5.2, I do not have the access to the BaaN-4 now...

I guess it must be in the program script.

I wonder if UTC is available on that version or not.

Also, from my experience working in BaaN R & D, I guess it might be someway coding based on conversion from utc/time to string format in the older versions.

I dont have all the details now when the UTC conversion project was executed in BaaN-5 series. There were some functions developed then which are not available now.

:mad:

Well, just to drag this post out more - the UTC format has been backported to 4c4 very recently. This was done I believe for either conversion c4 to ERP, or backwards compatiblity..?

The Baan 4 info on UTC says it does not store the time portion of date/time yet, but does store the date according to UTC Compliance. So, obviously something still in development. A likely culpret.

I would report this to Baan for explaination and/or correction. If the time is correct in the session, querying the table would give you bad results. Tons of people query the Job table - no one has seen this problem? Maybe it's new. If it's correct in the table, the session is incorrect, also a problem for Baan.

Hi Lisa,

Maybe its a good idea to get clarification from the BaaN Support.

But here is my finding about the tttime domain on our system. The domain valid range is in between [00:2400] and the modulus/remainder < 60 which rounds to 60 seconds/minutes.

Based on the display format and the range, I think it might be handling by programming -

dat = dte$()
dat = (lval(dat(7;4)))
|* Current time in <hh:mm> format

From the help manual -

Syntax

string dte$()

Desription
This returns the current date and time in the format MMDDYYHHMMSS.
Notes
The standard variable date$ provides the current date in the format DDMMYY.
The standard variable time provides the current time in the format HHMM.
dte$() cannot be subscripted. To extract part of the return value, use a temporary string, as shown in the example below.
Return values
A string containing the current date and time.
Context
Bshell function.
Example
This example prints the current time in the format HH:MM:SS.
string dat(12)
dat = dte$()
print dat(7;2), ":", dat(9;2), ":", dat(11;2)

Hi,
I was just facing the same issue and found out that although the time displayed on form is Local time, the one stored in backend is GMT.