SQL-Query: Zeit umwandeln

[Carwyn]

Hallo miteinander,

okay, ich übersehe mit Sicherheit irgendetwas total simples, aber ich will das Thema abgehakt haben, von daher hoffe ich, dass Ihr mir weiterhelfen könnt.

In einer Oracle-Datenbank sind Zeiten hinterlegt, soweit ich das sehe in Sekunden. Beispiel: Die Uhrzeit 17:15 ist in der Datenbank hinterlegt als 62100000. Da das natürlich bei einer Abfrage im Result Set keinem was sagt, muss die Zeit also umgerechnet werden.

Zu diesem Zweck gab uns die Firma, deren Software in der Datenbank schreibt eine Umrechnungsformel, die im Grunde funktioniert, aber irgendwie doch nicht...

cast(floor(termin.startzeit/3600000) as varchar2(2)) || ':' || 

case 

  when (round((termin.startzeit/3600000)-floor(termin.startzeit/3600000))/(1/60)) < 10

  then '0' 

end || 

cast(round(((termin.startzeit/3600000)-floor(termin.startzeit/3600000))/(1/60)) as varchar2(2))

AS STARTZEIT

Wenn ich da richtig durchsteige, macht er folgendes:

1.) Er teilt den Wert durch 360000 und rundet den Wert ab, um die Stundenanzahl zu bekommen. In diesem Fall ist das Ergebnis 17,25, abgerundet 17. Das castet er dann in einen String, damit er konkatinieren kann und hängt einen Doppelpunkt dran.

2.) Er prüft ob der Ursprungswert (17,25) minus der abgerundeten Wert (17) geteilt durch 1/60 (was dem Minutenwert (15) entspricht), kleiner 10 ist. Ist dies der Fall, wird eine 0 geschrieben. Ist es nicht der Fall, wird an dieser Stelle nichts gemacht.

3.) Er gibt den Minutenwert (15) aus.

Rein der Logik folgend müsste er bei dem Beispiel sehen, dass 15 > 10 ist und dementsprechend keine 0 schreiben und als Ergebnis sollte ein String rauskommen in der Form: 17:15

Tatsächlich schreibt er aber 17:015. Dieses Verhalten zeigt er meiner Kenntnis nach bis zu einer Minutenzahl von 25, ab 30 verhält er sich korrekt und hängt keine 0 mehr dran.

Ich hab inzwischen einiges ausprobiert und bspw. die < 10 umgeändert in = 15, nur um zu sehen was passiert. Ergebnis war, dass er bei der 15 KEINE 0 anhing, dafür überall anders.

So ganz kann ich mir das Verhalten nicht erklären, denn im Grunde wirkt die Logik bei dem Statement schlüssig. Allerdings bin ich nicht der SQL-Crack und im Zweifel liegt es an irgendwelchen Hochkommata o.ä. weswegen der Case sich falsch verhält.

Wäre super, wenn mir jemand helfen könnte.

[Dragon8]

Dein Fehler dürfte bei 2.) liegen. Denn nachdem er den Stundenwert vom Ursprungswert abgezogen hat, rundet er erstmal, das heißt bei allem was < 0,5 ist, rundert er ab. Erst danach rechnet er die Minuten aus, sodass alles bis zur 30. Minute in der Rechnung < 10 ergibt, da die Minutenanzahl dann immer 0 ergeben hat.

Meiner Meinung nach müsste es so aussehen:

when (round((termin.startzeit/3600000)-floor(termin.startzeit/3600000)/(1/60))) < 10

Wobei das round() wahrscheinlich auch ganz weggelassen werden kann.

Bearbeitet 6. Dezember 2011 von Dragon8

[Carwyn]

Ich wusste doch, dass es nur so ein Mist sein konnte! Danke Dragon. Ich war irgendwie davon ausgegangen, dass round im Gegensatz zu floor immer aufrundet. Aber nein, dadurch dass er rundet nach Ergebnis, kam natürlich bis 0,49 immer 0 (und 0 * 60 ist nunmal 0 => < 10) raus und ab 0,5 immer 1. Das erklärt auch die Schwelle bei 30 Minuten!

Meine Lösung ist tatsächlich nichts anderes als den Ausdruck ohne round zu nehmen. Also:

when (((termin.startzeit/3600000)-floor(termin.startzeit/3600000))/(1/60)) < 10

Bist ein Schatz! :e@sy

[Thelvan]

dass round im Gegensatz zu floor immer aufrundet.

Das wäre ceil

[Carwyn]

Das wäre ceil

DAS ist mir jetzt auch wieder bewusst.

Ich wusste doch, dass es wieder irgendwas total dämliches ist. Aber lieber einmal gefragt und dumm für einen Tag sein, als dumm für's Leben sein.

[streffin]

Was ich in so Fällen immer ganz gerne mache ist folgendes :

(TSQL)

right('0' + convert(varchar(2), [minuten als integer]) , 2) 

Also im Endeffekt immer die 0 anverketten, und dann die letzten 2 Zeichen des resultierenden Strings. Das gibt dir immer eine 2 stellige Angabe, ohne dass da was schief gehen kann. Sollte auch recht performat sein denke ich, so viel ist da an Aufwand nicht dahinter bei ner String Verkettung nen nem Substring.....

Gruß

Sven

Bearbeitet 6. Dezember 2011 von streffin