cl_abap_tstmp=>systemtstmp_utc2syst
4 Beiträge
•
Seite 1 von 1
4 Beiträge
Seite 1 von 1
Hallo Zusammen,
es wird die Methode cl_abap_tstmp=>systemtstmp_utc2syst verwendet um die Zeit von UTC auf Systemzeit (CET) umzurechnen.
Die letzten Jahre seit 2020 und aktuell hat das auch immer beim MSCONS import fehlerfrei funktioniert, nur in einem Fall nicht.
LV_TIMESTAMP_1 = 20241027003046
LV_DATE = 20241027
LV_TIME = 021523
Erwartet hätte ich 20241027023046 bei der Umrechnung von UTC auf CET kommen 2 bzw, 1 Stunde hinzu, aber die Minuten und Sekunden ändern sich dadurch nicht.
20241027023046 ist in der "Bösen" Stunde = Zeit Umstellung von 03:00 auf 02:00.
Es kann durchaus sein, dass noch nie eine Nachricht in der "Bösen" Stunde versendet wurde und es daher nicht aufgefallen ist
bei einer analogen Anpassung (2020) in einem anderen import für die zur MSCONS korrespondierende IFTSTA wurde dies verwendet und das rechnet korrekt
ls_rff_8-referencenumber = 20241027003046+00
lv_tstamp = 20241027023046
Hat jemand eine Idee was die Methode da treibt oder für ein Problem hat?
Lösung: ich lasse die Methode durch den Funktionsbaustein ersetzen, aber ich würde trotzdem gerne verstehen, was da schief läuft.
es wird die Methode cl_abap_tstmp=>systemtstmp_utc2syst verwendet um die Zeit von UTC auf Systemzeit (CET) umzurechnen.
Die letzten Jahre seit 2020 und aktuell hat das auch immer beim MSCONS import fehlerfrei funktioniert, nur in einem Fall nicht.
Code: Alles auswählen.
CALL METHOD cl_abap_tstmp=>systemtstmp_utc2syst
EXPORTING
utc_tstmp = lv_timestamp_1
IMPORTING
syst_date = lv_date
syst_time = lv_time.LV_DATE = 20241027
LV_TIME = 021523
Erwartet hätte ich 20241027023046 bei der Umrechnung von UTC auf CET kommen 2 bzw, 1 Stunde hinzu, aber die Minuten und Sekunden ändern sich dadurch nicht.
20241027023046 ist in der "Bösen" Stunde = Zeit Umstellung von 03:00 auf 02:00.
Es kann durchaus sein, dass noch nie eine Nachricht in der "Bösen" Stunde versendet wurde und es daher nicht aufgefallen ist
bei einer analogen Anpassung (2020) in einem anderen import für die zur MSCONS korrespondierende IFTSTA wurde dies verwendet und das rechnet korrekt
Code: Alles auswählen.
lv_date = ls_rff_8-referencenumber+(8).
lv_time = ls_rff_8-referencenumber+8(6).
CALL FUNCTION 'ISU_DATE_TIME_CONVERT_TIMEZONE'
EXPORTING
x_date_utc = lv_date
x_time_utc = lv_time
x_timezone = 'CET'
IMPORTING
y_date_lcl = lv_date
y_time_lcl = lv_time
EXCEPTIONS
general_fault = 1
OTHERS = 2.
IF sy-subrc EQ 0.
CONCATENATE lv_date lv_time INTO lv_tstamp.
ENDIF.lv_tstamp = 20241027023046
Hat jemand eine Idee was die Methode da treibt oder für ein Problem hat?
Lösung: ich lasse die Methode durch den Funktionsbaustein ersetzen, aber ich würde trotzdem gerne verstehen, was da schief läuft.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Er ruft in der Methode nochmal zusätzlich die Methode SYSTEMTSTMP_LOC2SYST auf, in der er prüft, ob der genutzte Zeitstempel innerhalb der Stunde der Zeitumstellung liegt. Falls dem so ist, ermittelt er den Anfang dieser Stunde (2:00 Uhr), die halbe Differenz in Sekunden zum ursprünglichen Zeitstempel (30 Minuten 46 Sekunden = 1846 Sekunden -> hälftig 923 Sekunden = 15 Minuten und 23 Sekunden) und summiert diese halbe Differenz dann zum Stundenanfang wieder drauf. Daher erhälst du am Ende 2:15:23 zurück statt 2:30:46. Im Grunde ist hier nur die Frage, wieso er die Sekundendifferenz halbiert.
Glücklicherweise kannst du das Ganze aber einfach mit convert ersetzen:
Glücklicherweise kannst du das Ganze aber einfach mit convert ersetzen:
Code: Alles auswählen.
data:
lv_date type d,
lv_dst type boolean_flg value abap_true,
lv_time type t,
lv_timestamp type timestamp value '20241027003046'.
convert time stamp lv_timestamp time zone sy-zonlo into date lv_date time lv_time daylight saving time lv_dst.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Zur Info:
Das ist die "verzögerte" Doppelstunde, welche die SAP für solche Fälle eingeführt hat, damit im System bei einer Zeitumstellung nicht zweimal etwas zur selben Zeit gebucht wird. Im Grunde werden hier für die Verarbeitung zwei Stunden die in Wirklichkeit vergehen auf eine Stunde komprimiert.
https://community.sap.com/t5/additional ... p/12902283
Aus diesem Grund sollte man bei neuen Implementierungen die zeitkritische Komponenten haben intern IMMER mit UTC arbeiten und die ganze Umrechnung inkl. Zeitumstellung erst ganz am Schluss in der (lokalen) Ausgabe der Daten realisieren.
Das ist die "verzögerte" Doppelstunde, welche die SAP für solche Fälle eingeführt hat, damit im System bei einer Zeitumstellung nicht zweimal etwas zur selben Zeit gebucht wird. Im Grunde werden hier für die Verarbeitung zwei Stunden die in Wirklichkeit vergehen auf eine Stunde komprimiert.
https://community.sap.com/t5/additional ... p/12902283
Aus diesem Grund sollte man bei neuen Implementierungen die zeitkritische Komponenten haben intern IMMER mit UTC arbeiten und die ganze Umrechnung inkl. Zeitumstellung erst ganz am Schluss in der (lokalen) Ausgabe der Daten realisieren.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
A6272
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Seite 1 von 1
Vergleichbare Themen
3
Antw.
Antw.
569
Views
Views
5
Antw.
Antw.
11216
Views
Views
Kundeneigene ABAP-Muster Vorlage im ABAP-Editor anlegen
von Stentor » 19.07.2005 11:10 • Verfasst in Basis
von Stentor » 19.07.2005 11:10 • Verfasst in Basis
2
Antw.
Antw.
3827
Views
Views
6
Antw.
Antw.
5535
Views
Views
ABAP Workbench und ABAP Dictionary - für Einsteiger
von schnonus » 03.04.2008 10:39 • Verfasst in ABAP® für Anfänger
von schnonus » 03.04.2008 10:39 • Verfasst in ABAP® für Anfänger
3
Antw.
Antw.
4246
Views
Views
OLE und ABAP: Aufruf von Excel-VBA Prozeduren aus ABAP
von OnkelSAP » 26.05.2010 09:45 • Verfasst in ABAP Objects®
von OnkelSAP » 26.05.2010 09:45 • Verfasst in ABAP Objects®
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1138
vor 2 Tagen von DeathAndPain 4 / 1138
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1138
vor 2 Tagen von DeathAndPain 4 / 1138