SQL/Systemzeit per Stored Procedure auslesen

[robroy85]

@marabu

ich habe die Funktion GetUTCDate dann auch in der MSDN unter MS SQL 2000 gefunden und mir ist der fehler klar geworden.
Ich habe sie als procedure hinzugefügt, jedoch ist sie doch vom Output gleich wie getdate "nur" das die Zeitzone und Winter/Sommerzeit berücksichtigt wird.

Leider habe ich das mit dem gebrochenen anteil * 60*60*24 nicht verstanden!
Villeicht hilft ja auch die Erläuterung in meinem vorletzten Post weiter?

Wie konvertiere ich den das datetime-format in einen integerwert?
ich hatte schon mit Convert([..],getdate()) versucht, aber da ist nix gescheites bei raus gekommen

schönen gruß robert

[marabu]

Hallo Robert,

Zitat von robroy85:

Ich habe sie als procedure hinzugefügt, jedoch ist sie doch vom Output gleich wie getdate "nur" das die Zeitzone und Winter/Sommerzeit berücksichtigt wird.

Ist doch genau die Zeit, die du brauchst. Werfe den ersten Entwurf weg und nimm die hier - die hat einen Ausgabeparameter:

SQL-Code:

IF EXISTS (
  SELECT name FROM sysobjects 
    WHERE name = 'GetUTCDate' AND type = 'P'
) DROP PROCEDURE GetUTCDate

CREATE PROCEDURE GetUTCDate
  @utc DATETIME OUTPUT
AS 
BEGIN
  DECLARE @BiasInMinutes INT
  EXEC master.dbo.xp_regread 'HKEY_LOCAL_MACHINE', 
    'SYSTEM\CurrentControlSet\Control\TimeZoneInformation', 
    'ActiveTimeBias', 
    @BiasInMinutes OUTPUT
  SELECT @utc = DATEADD(MINUTE, @BiasInMinutes, GetDate())
END

Zitat von robroy85:

Leider habe ich das mit dem gebrochenen anteil * 60*60*24 nicht verstanden!

Vergiss den gebrochenen Anteil - Denkfehler von mir - war schon beim Einkaufen...

Zitat von robroy85:

Wie konvertiere ich den das datetime-format in einen integerwert?

Vergiss das auch wieder, du hast in MSSQL 7 noch keinen Datentyp BigInt. So hast du schon mal die UTC-Zeit in Sekunden:

SQL-Code:

DECLARE @utc DATETIME
DECLARE @seconds FLOAT
EXEC getutcdate @utc OUTPUT
SELECT @seconds = CONVERT(FLOAT, @utc) * 86400

Jetzt fehlt nur noch die Schleife, die aus dem Float-Wert einen Hex-String macht, aber das kriegen wir auch noch hin.

marabu

[robroy85]

Ich habe nun eine recht simple UNIX_timestam-stored procedure erstellt. Mit dem Ergebnis von CONVERT(FLOAT, @utc) * 86400 konnte ich leider nichts anfangen. die SP erzeugt nun das gleiche Ergebnis wie die delphi-funktion IntToStr(DateTimeToUnix(Now))

SQL-Code:

CREATE PROCEDURE sp_timestamp 

AS
  DECLARE @jahr int
  DECLARE @sec int 
  SELECT @jahr = 1970
  SELECT @sec = 0

WHILE (CONVERT (int, DATEPART (yyyy, getdate())) > @jahr)
BEGIN
   if ( @jahr % 4 ) = 0 AND (@jahr % 100)<>0 OR (@jahr % 1000) = 0  
      SELECT @sec = @sec + 366*24*60*60
   ELSE SELECT @sec = @sec + 365*24*60*60 
      SELECT @jahr = @jahr +1
END

SELECT @sec = @sec + (CONVERT (int, DATEPART (dy, getdate()))-1)*24*60*60
SELECT @sec = @sec + CONVERT (int, DATEPART (hh, getdate()))*60*60
SELECT @sec = @sec + CONVERT (int, DATEPART (mi, getdate()))*60
SELECT @sec = @sec + CONVERT (int, DATEPART (ss, getdate()))

PRINT  @sec  
PRINT 'Sekunden sind vergangen seit dem 01.01.1970 00:00:00' 
SELECT getdate()

ERGEBNIS:
1129761963
Sekunden sind vergangen seit dem 01.01.1970 00:00:00

---------------------------
2005-10-19 22:46:03.187

(1 row(s) affected)

Jetzt muss nur noch das ganze in eine HEX-zahl umgewandelt werden. Gibt es dafür wirklich keine T-SQL Funktion ?

Schönen Gruß

Robert

[Jelly]

Zitat von robroy85:

Jetzt muss nur noch das ganze in eine HEX-zahl umgewandelt werden. Gibt es dafür wirklich keine T-SQL Funktion ?

Nicht dass ich wüsste. Hier aber ne schnelle Lösung in Delphi um dezimal in hexadezimal umzuwandeln. Sollte dann nicht so schwer sein, das in T-SQL umzucoden:

Delphi-Quellcode:

const
 Trans : array[0..15] of char = ('0','1','2','3','4','5','6','7','8','9',
                                 'A','B','C','D','E','F') ;

function DecToHex (ID : integer) : string ;
begin
  Result := '' ;
  while ID <> 0
  do begin
          Result := Trans[ID mod 16] + Result ;
          ID := ID div 16 ;
     end ;
  if Result = '' then Result := '0';
end ;

[marabu]

Mit einer kleinen Anpassung bei GetUtcDate wird die Zeitbasis auf den Beginn des Jahres 1900 1970 umgestellt:

SQL-Code:

CREATE PROCEDURE DateTimeToUnix
  @unixtime FLOAT OUTPUT
AS
BEGIN
  DECLARE @BiasInMinutes INT, @RefDate DATETIME
  SELECT @RefDate = CONVERT(DATETIME, '19700101')
  /* ab MSSQL 2000 gibt es dann GetUtcDate */
  EXEC master.dbo.xp_regread 'HKEY_LOCAL_MACHINE',
    'SYSTEM\CurrentControlSet\Control\TimeZoneInformation',
    'ActiveTimeBias',
    @BiasInMinutes OUTPUT
  SELECT @unixtime = CONVERT(FLOAT, DATEADD(MINUTE, @BiasInMinutes, GetDate()) - @RefDate)
END

Für die Konvertierung in einen Hex-String muss das hier herhalten:

SQL-Code:

/* ab MSSQL 2000 gibt es 64-bit integers */ 
CREATE PROCEDURE IntToHex
  @int INT,
  @len INT,
  @hex VARCHAR(8) OUTPUT AS
BEGIN
  DECLARE @i INT, @q INT, @nibble INT

  IF @len > 8 SELECT @len = 8
  SELECT @hex = ''
  WHILE (@int > 0) or (len(@hex) < @len)
  BEGIN
    SELECT @nibble = @int % 16
    SELECT @int = @int / 16
    SELECT @hex = substring('0123456789abcdef', @nibble + 1, 1) + @hex
  END
END

Und überprüfen kann man es so:

SQL-Code:

DECLARE @f FLOAT, @sec INT, @frac INT, @hs VARCHAR(8), @hf VARCHAR(2)
EXEC DateTimeToUnix @f OUTPUT
SELECT @sec = FLOOR(@f * 86400)
SELECT @frac = Floor((@f * 86400 - @sec) * 256)
EXEC IntToHex @sec, 8, @hs OUTPUT
EXEC IntToHex @frac, 2, @hf OUTPUT
SELECT @hs + @hf

Grüße vom marabu

[robroy85]

Danke für die Programmierungen!
Ich hab die Zeilen nachvollzogen und mir ist noch was aufgefallen. Soweit ich das verstehe wird die Zeitbasis nicht auf den Beginn des Jahres 1900 gerechnet, sondern wird, wie unten zu sehen, von der aktuellen Zeit, beginnend im Jahr 0, die vergangene Zeit seit dem UNIX-Zeitstart 1970 abgezogen!

[quote="marabu"]Mit einer kleinen Anpassung bei GetUtcDate wird die Zeitbasis auf den Beginn des Jahres 1900 umgestellt:

SQL-Code:

...
  SELECT @RefDate = CONVERT(DATETIME, '19700101')
...
  SELECT @unixtime = CONVERT(FLOAT, DATEADD(MINUTE, @BiasInMinutes, GetDate()) - @RefDate)
...

Ist das soweit korrekt?

Spricht denn ansonsten was gegen meine Errechnung der UNIX-Zeit?


Schönen Gruß und danke nochmal!

Robert

[marabu]

Hallo Robert,

dein Ansatz ist schon okay, ich wollte meinen Kram nur für spätere Leser in eine Form bringen, die eine sinnvolle Verwertung ermöglicht. Die 1900 war natürlich ein Schreibfehler - habe ihn schon korrigiert.

Grüße vom marabu