I created Data element ZDT_NKS_DESCR and flagged Change Document when creating for logging the changes on WebUI table. Everything is good, but the time of changing logging wrong. It adds +3 hours to current time.
For example: if the current time is 10:00 it's logging 13:00 on Web UI.
How can I fix it? Can anybody explain what happens?
Here is my data element (NB: in fact I ticked the "Change Document" checkbox later on):
Here is the change logging on Web UI table, the time should be 9:48, 9:48, 9:45 :
P.S: On Web UI timezone is correct.
In ABAP-based softwares, many screens display the dates using the SAP system time unfortunately (that's been always a big problem). Some modules sometimes display the local time (according to user's time) or according to the local time of the partner (transportation modules for instance). So users have to learn for every module or every screen what kind of date/time it is.
Even in database tables, it's impossible to be sure what kind of date/time it is. Usually it's the system time. But some modules may store the date/time according to UTC.
I guess that the times of the change documents are displayed in the system time.
The system time can be seen via the classic SAP GUI, in the menu System > Status > System time.
Here's my final solution based on Sandra answer:
In xxxxx_WRITE_DOCUMENT FM we should change time_of_change value from utime to sy-uzeit. Your CHANGEDOCUMENT_CLOSE function should look like this:
CALL FUNCTION 'CHANGEDOCUMENT_CLOSE'
EXPORTING
objectclass = 'ZCHD00005'
objectid = objectid
date_of_change = udate
time_of_change = sy-uzeit (it's current system time)
tcode = tcode
username = username
object_change_indicator = object_change_indicator
no_change_pointers = no_change_pointers
EXCEPTIONS
header_insert_failed = 1
object_invalid = 2
open_missing = 3
no_position_inserted = 4
OTHERS = 5.
If it's necessary, you should change the timezone on WebUI. I'm using system timezone, because of this on WebUI->Personalization->Timezone I choose UTC from F4.
Save and activate your solution!
Related
I set a winforms combobox with the time zones DisplayName:
var zoneList = TimeZoneInfo
.GetSystemTimeZones()
.Where(z => z.BaseUtcOffset.Minutes == 0)
.Select(z => z.DisplayName);
It shows a list like this:
...
(UTC-01:00) Azores
(UTC-01:00) Cabo Verde Is.
(UTC) Casablanca
(UTC) Co-ordinated Universal Time
(UTC) Dublin, Edinburgh, Lisbon, London
(UTC) Monrovia, Reykjavik
(UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna
...
I want to sent the default item to (UTC) Co-ordinated Universal Time. However, TimeZoneInfo.Utc.DisplayName returns UTC. It is unusual because the upper enumeration shows different DisplayName.
TimeZoneInfo.FindSystemTimeZoneById("UTC") also returns "UTC".
TimeZoneInfo.FindSystemTimeZoneById("(UTC) Co-ordinated Universal Time") and TimeZoneInfo.FindSystemTimeZoneById("Co-ordinated Universal Time") do not work.
How to get the localized string that corresponds to shown in the enumeration (UTC) Co-ordinated Universal Time?
The only solution I can figure out is to store the string "(UTC) Co-ordinated Universal Time", but I'm afraid the upper list may change in different localization.
A few things:
The DisplayName is not the ID. Only the values returned by the Id property are suitable for use with the FindSystemTimeZoneById method.
For your dropdown list, you should show the DisplayName, but you should store only the Id.
The DisplayName, StandardName and DaylightName properties are localized by the operating system, not by the globalization features of the .NET Framework.
The IDs will always be in English. They will never change for localization.
You should never show the IDs to the end-user or interpret them in any particular way. There are many different conflicting conventions used, and some that are just made up. See the section on Windows time zones in the timezone tag wiki for some examples.
"Coordinated" is a single non-hyphenated word. These are correct in Windows, so I think you must have added the hyphen yourself.
Recognize that the offsets shown in the display names are just the base offsets. They do not indicate whether or not the time zone adjusts for daylight saving time or not. Nor do the offsets in this list change when daylight saving time is in effect.
You are correct that TimeZoneInfo.Utc.DisplayName == "UTC", and so does TimeZoneInfo.FindSystemTimeZoneById("UTC").DisplayName. However, the UTC entry returned by TimeZoneInfo.GetSystemTimeZones() has the full form of the display name: "(UTC) Coordinated Universal Time". Therefore, if you're displaying a dropdown list by enumerating the results from TimeZoneInfo.GetSystemTimeZones(), then you can just use the results as-is.
But if you want to get that display name directly, you will either have to do this:
string s = TimeZoneInfo.GetSystemTimeZones().First(x => x.Id == "UTC").DisplayName;
Or, this:
string key = #"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\UTC";
string s = Registry.GetValue(key, "Display", null) as string;
Again, remember that all localization of time zone display names is done by the operating system. Therefore, this approach works fine for Windows desktop applications, but doesn't make a whole lot of sense for web apps. Also, if your application supports multiple languages internally, you won't be able to rely on .NET Globalization for any time zone display names. In that scenario, you will need to provide your own source of display names, perhaps in a .resx file, or you can look into using my TimeZoneNames library.
Hmm, I found the answer by printing the time zone's Id.
The desired string is printed with:
TimeZoneInfo.FindSystemTimeZoneById("GMT Standard Time"); // Wrong
Edit:
As Matt Johnson noted, the above code shows the London time zone.
Here is another try:
TimeZoneInfo.GetSystemTimeZones().First(t=>t.Id=="UTC").DisplayName
I have an MVC 4 application with international users (all over the world). I want to add a new page called profile settings where users can select their regional settings and by that I mean that they should be able to select:
- time zone (UTC +- .....)
- date format (dd.MM.yyyy or dd/MM/yyyy or MM/dd/yyyy ....)
- time format (12/24 - AM PM)
- number format (1234.56 or 1234,56)
After the user selects his regional settings, all specific data (date, time, number ...) should be shown in that specific format.
Any advice how to make this work?
Most of the time, you shouldn't expose each and every detail of the culture format to your users. Instead, provide a drop-down list of cultures you want to support. Cultures are specified using codes. Some common codes are en-US (English/USA), es-MX (Spanish/Mexico) and de-DE (Germany/German). The first part refers to the language, and the second part refers to the specific country or region.
Once you have the selected culture code, you can apply it to each user, such as:
CultureInfo culture = new CultureInfo("en-US");
Thread.CurrentThread.CurrentCulture = culture;
If you are using culture-specific resource files, then you will also need:
Thread.CurrentThread.CurrentUICulture = culture;
There are several places you could do this, but a common location is in the Application_BeginRequest event in your global.asax file.
There is a good tutorial on MSDN here.
While it is common to think about time zones when you are considering regional settings, they are actually quite different things and should be considered separately. Time zones can't really be set globally, you need to consider how they affect your application logic in each and every place you work with date and time. You should look into the TimeZoneInfo class. If you have questions, please ask separately. Although if you search, you may find that many have already been answered.
I'd like to force the user to chose between Yes and No, and not let him add an entry where the value is initial.
This is regardless of whether I check the Initial checkbox in the table definition.
Can this be done?
Domain data type : CHAR, 1 character, no conversion routine.
Value range: single values:
'1' description = 'Yes'
'2' description = 'No'
By far the easiest way is to use a data element in the table that only allows non-initial values.
If you can't change the data element, you can try using table maintenance events in the table maintenance generator:
You may be able to use event 1 (Before save) or event 5 to build a manual check, but 5 does not kick off on change.
If that doesn't work, you can still manually add a check in the PAI of the screen, however you run the risk that if someone regenerates the maintenance scree, they will forget/not know to put the check back in.
You can set the compare flag:
But from what I've seen the flag doesn't actually force you to redo any of the changes, and is still pretty easy to miss.
You can edit the screen and set the field to mandatory. Be aware that you will loose the change if the screen is re-generated.
You can do that with that steps:
in SE11 choose the Utilities menu -> Table Maintenance Generator
in the Table Maintenance Generator go to menu Environment -> Modification -> Maintenance Screens, then select the screen (usually is 0001), in the Element List Tab you find the Special attr, in the field Input, you choose Required for the field you want obligatory.
Thanks.
Regards.
Gil Mota.
Here is the problem.
I have to create a submission form on my Yii-based website. The form requires to enter a datetime range.For that I am using "jui datetimepicker" third-party Yii extension.
http://www.yiiframework.com/extension/datetimepicker/
I use two date fields with this extension pertaining to start and end time respectively. So, what I want to achieve is be able to restrict the start datetime only to time in the future (neither past dates nor time should be selected) and the end time itself should be restricted to the maximum of three hours following the start time.
EXAMPLE: a user wants to schedule an event. They choose a date and time, which are of course in the future. Let's say they choose March 15, 13 O'clock as the start time in the start time field. Once they are done and move to the next field ("end time"), the respective datetimepicker restricts the range of time from March 15, 13:00 to March 15, 16:00.
Hence the second datetimepicker should be dynamically updated depending on the input of the first one.
It's possible o specify date range in the datetimepicker starting from the current date, but there is nothing like that for the time selection, so a user still can select time which has already passed.
It's not that I want to solve this problem with this extention, if anybody has any suggestions about YII solutions allowing to specify a datetime range in the most clean and effective way - it would be much appreciated.
You should use the edaterangepicker extension instead.
Given the API for the jquery timepicker addon. you should add the following to your widget call (along side 'model','attribute', etc)
'options'=>array(
'minDateTime'=>'<start dateTime here>',
'onSelect'=>'<JS function to run>'
)
The function you run on the "onSelect" event should dynamically set the minDateTime for the second dateTime input field, for ex:
function (selectedDateTime){
<EndDatePickerElement>.datetimepicker('option', 'minDateTime', <start dateTime here using selectedDateTime> );
}
There are more examples on the link provided earlier if you need to make it even more precise (like say if you wanted the starting date to be pushed back by the amount of time the user was on the page rather than it being set when the page was loaded. etc...)
FYI to start, I am aware of how to properly set up an update to a lookup, and am 99% positive I've done this correctly.
I know this because When I set the workflow to automatically start when an Item is Changed, then it works perfectly. But when I simply change this setting so it will automatically start on New Item Creation, it Cancels the workflow and I get a "Coercion Failed: Unable to transform the input lookup data into the requested type." If both options are checked then it fails on creation, but simply clicking edit on the item properties, and the "Save" makes it work.
The workflow is on a Document Library and works as follows;
User selects the Work Task LookUp from a dropdown in the edit properties form after uploading, and then Saves the item (adding it to the document library). The workflow is suppose to then look at the Work Task LookUp selected, and pull the Account and Effective Date-Type lookUp ID's that Work Task item has, and sets the Document's identical fields to the same value.
Here is the code for the workflow if it helps;
If Current Item: Parent Task is not empty
If Current Item: Sub Task is not empty
Log Both are empty to workflow history list
Then Set Account to Work Tasks:Account
The Log Set Account to workflow history list
Then Set Effective Date and Type to WorkTasks: Effective Date and Type
The Log Set EffDateType to the workflow history list
This is all done in one step. I also added additional steps to test if the account and effective date type fields have been set properly, and if not to set them again. But everytime I run the workflow on change and it works, it always correctly sets these fields based upon the first Step (posted above) and the additional check logs to the history that they are not needed.
As an example, The lookUp for Integer for Tasks:Account is set to work as follows;
Date Source: Work Tasks (a list)
Field from Source: Account (a lookup)
Return Field as: Lookup ID (as Integer)
Find the List Item
Field: Title (from the Work Tasks list)
Value: Current Item: Parent Task (Which is a look up of the "Title"
Field from Work Tasks List, and is set to return the Value as a LookUp Value (As Text))
The Effective Date and Type setting is pretty much identical.
So anyone have any insight? I've tried running it as an impersonated Step, setting a workflow pause (for 1 minute), changing the lookup types incase I messed it up to start with, but ultimately the above workflow DOES work, but only when I set it to "Automatically start on the Change (edit) of an Item", NOT "Automatically start on New Item Creation" like I need to to do.
Oh yes, fyi, I am using SPServices CascadingDropDown on the Work Task and Sub Task fields of the doc Library form, but I honestly do not believe this has anything to do with my issue.
UPDATE:
I've talked with another developer, and he believes it is due to the issue that the workflow is occuring too quickly, before the item creates an ID for itself, which it needs to conduct the lookUps. He had me add another "Pause Workflow" to the very top of my workflow code (above the If conditions) and set it for 1 minute.
It then worked properly.
Downside is we want this to labeling to occur as close to item creation as possible. Because a view of the library relies on grouping based upon Account and Effective Date and Type. To add to this downer, Microsoft's Pause Workflow only allows for 1 minute or more, and then the timer used for this is often off, resulting in a pause longer than that. So far, every test is currently showing 2 minutes minimum on the pause.
A possible alternative solution for instantaniously populate the fileds is to use Javascript and SPServices to do the lookUp to the Task list to pull the account and effective date - type fields and then populate, but my Javascript is not very strong and I would need help doing this. If anyone has any suggestions, I would appreciate them.
(Answered in a question edit. Converted to a community wiki answer. See Question with no answers, but issue solved in the comments (or extended in chat) )
The OP wrote:
I don't know if it is the ID for the item after further testing. I changed the start of the workflow to wait until a field in the item changes. I set it to wait until the ID field is not 0 (since you cannot set to null), and it still does not work.
6/14/2012 4:13 PM Comment System Account Waiting on ID
6/14/2012 4:13 PM Comment System Account Waiting complete on ID
6/14/2012 4:13 PM Error System Account Coercion Failed: Unable to transform the input lookup data into the requested type.
I have tried other fields as well, like document ID value is not empty, and it will wait, log it finishing the wait, and then fail.
UPDATE This issue has something to do with the Parent Task field. I have solved the issue without having to wait for a period of time by setting the change from above to wait until the Parent Task field is not empty. It then completes the workflow fine.
Anyone know why there is a delay though? I've solved it, but still don't fully understand what takes it so long.
The main fault has been solved (hence the answer), and the remaining point about the reasons for the delay would probably be a discussion point or not specific enough for SO. Any further clarification can be edited in here.