Comment puis-je convertir DB2 TIMESTAMP au format UTC millisecondes?

Est-il une base de données DB2 fonction pour convertir TIMESTAMP à UTC milliseconds?

êtes-vous essayer de le faire en SQL?
Principalement Oui. Toutefois, si nécessaire, je peux aussi créer une fonction locale.
Pourquoi? Et quelle est votre application de couche? Vous pouvez avoir les meilleurs résultats/plus facile d'effort si vous stocker le tout dans les horodatages UTC, puis de les convertir à l'application, avec une bonne bibliothèque (comme JodaTime, pour Java).

OriginalL'auteur JSS | 2013-02-26

  1. 2

    En supposant que vous êtes à la recherche pour obtenir le nombre de millisecondes écoulées depuis l'époque (1970-01-01 00:00:00), il n'y a pas une fonction intégrée pour ce faire.

    Cependant, il est trivial de créer une fonction qui peut:

    CREATE OR REPLACE FUNCTION utcmillis (in db2ts timestamp)
   returns bigint
   language sql
   deterministic
   no external action
   return (
      bigint((days(db2ts - current timezone) - days('1970-01-01-00.00.00.000000')) * 86400 + midnight_seconds(db2ts - current timezone))*1000 + microsecond(db2ts)/1000
   );
    Malheureusement, les jours ne sont pas toujours 86400 secondes long de votre code n'est pas sûr de l'heure d'été. En outre, je ne suis pas sûr si comment IBM poignées de fuseaux horaires est correct, car ils semblent être en utilisant seulement "compensées" définitions, qui traitera de tous les fuseaux horaires dans la même longitude, la même; tous les pays de l'interrupteur de l'heure d'été en même temps... en Outre, ce code peut être en supposant que les horodatages comprennent toutes un fuseau horaire, et sont au "courant" - ce qui peut ne pas être le cas. Maintenant, si tous les horodateurs ont été à l'UTC, et que vous ne faites pas n'importe quoi avec le fuseau horaire, ce qui devrait probablement travailler.
    Pendant que vous êtes techniquement correcte qu'il n'y a pas toujours de 86 400 secondes dans une journée, la logique dans ce UDF va produire la même valeur qu'un appel à la UNIX mktime() pour une fonction donnée de date/heure (à l'exclusion de l'millisecondes, bien sûr, depuis mktime() n'a pas subsecond résolution).
    Comme pour les fuseaux horaires: DB2 utilise le CURRENT TIMEZONE registre spécial de décider comment gérer une valeur d'horodatage. DB2 définit la valeur de la CURRENT TIMEZONE inscrire en interrogeant le système d'exploitation du moment où une instruction SQL est exécutée. Donc, si vous exécutez l'instruction VALUES CURRENT TIMEZONE, puis modifiez le fuseau horaire sur le serveur de base de données, et d'exécuter la même VALUES CURRENT TIMEZONE relevé à nouveau, DB2 rapport au nouveau fuseau horaire.
    Si db2ts est un timestamp local, et sur une journée au cours de l'heure d'été, alors non, ce n'est pas donner des résultats corrects - après tout, l'ajustement de fuseau horaire ne va compenser en quelques heures, et la différence se fait "tronqué'. Si c'est un horodatage UTC, puis le fuseau horaire n'a pas d'importance...
    CURRENT TIMEZONE spécifie le décalage actuel de l'UTC, et la valeur d'un système de modifier lorsque l'heure d'été commence ou se termine. Sur mon système, la valeur est actuellement -80000 (c-à -8h, 00m, 00s). Mais dès que nous passons à l'heure d'été, le CURRENT TIMEZONE registre de commencer immédiatement le retour -70000.

    OriginalL'auteur Ian Bjorhovde

  2. 0

    Vous pouvez utiliser TIMESTAMPDIFF. Quelque chose comme ceci:

    TIMESTAMPDIFF(1,CHAR(timestampField -
    TIMESTAMP('1970-01-01-00.00.00.000000')))

    En supposant que vous dire de millisecondes écoulées depuis l'époque unix. Je n'ai pas tester cela, et vous pourriez avoir à ajuster la valeur par un facteur de 10 en tant que db2 documentation ne dit Fractions de seconde.

    Malheureusement.... non (je souhaite). Deux raisons: 1) La sortie de TIMESTAMPDIFF() est limitée à 'INTEGER', ce qui limite automatiquement la taille, il peut être (pour secondes, ce qui signifie la fin de l'époque est 2038). 2) la sortie de La différence des deux timestamps est imprécise intervalle, qui est pourquoi la fonction ne peut retourner qu'un DEVIS (je veux dire, sérieusement, IBM?) - c'est parce que l'intervalle est divorcée de l'information susceptible de l'aider à déterminer l'information nécessaire, comme l'heure d'été, ou les années bissextiles.
    bien dit. Je n'ai pas creuser si profond.
    TIMESTAMPDIFF() est la pire chose jamais. Une bonne règle de base est que vous ne devriez jamais, jamais utiliser.

    OriginalL'auteur Lucas