• FromUnixTimeSeconds(…) (und FromUnixTimeMilliseconds(…))
• ToUnixTimeSeconds(…) (und ToUnixTimeMilliseconds(…))

010203040506070809

  // UNIX-Zeitstempel für aktuelles Datum und aktuelle Uhrzeit ermittelnlong unixTimestamp = DateTimeOffset.UtcNow.ToUnixTimeSeconds();
  // bestimmtes Datum um 0:00 Uhr verwendenunixTimestamp = (new DateTimeOffset(new DateTime(1988, 1, 29))).ToUnixTimeSeconds();

  // DateTime-Objekt lokaler Zeit aus UNIX-Zeitstempel erzeugenDateTime dateTime = DateTimeOffset.FromUnixTimeSeconds(unixTimestamp).LocalDateTime;

Dynamisch vs. Statisch

Bei der statischen Typprüfung sind die Typen bereits zum Zeitpunkt der Entwicklung bekannt und werden entweder explizit vom Entwickler angegeben, oder aber implizit vom System abgeleitet (mehr dazu im nächsten Abschnitt). Bei der dynamischen Typprüfung findet die Prüfung der Typen erst zur Laufzeit statt.

• Dynamisch: z. B. C++ (optional), C# (optional), JavaScript, Lua, PHP, Prolog, Python, Ruby, Scheme
  Beispiele in C# und PHP

  01020304050607

    // C#dynamic age = 27;              // zur Laufzeit als "int" erkanntdynamic firstName = "Holger";  // zur Laufzeit als "string" erkannt
    // PHP$age = 27;                     // zur Laufzeit als "int" erkannt$firstName = "Holger";         // zur Laufzeit als "string" erkannt

• Statisch: z. B. Ada, C++ (standardmäßig), C# (standardmäßig), Haskell, Java
  Beispiele in C++ und C#

  01020304050607

    // C++int age = 27;                      // Ganzzahlstd::string firstName = "Holger";  // Zeichenkette
    // C#int age = 27;                      // Ganzzahlstring firstName = "Holger";       // Zeichenkette

Ich bevorzuge hier, sofern die Umstände nicht dagegen sprechen, die statische Typisierung. Für mich überwiegt hier der Vorteil der Typprüfung zur Entwicklungs- bzw. Kompilierzeit. Viele Fehler, die oftmals erst während der Laufzeit auffallen, können so effektiv vermieden werden. Durch Konzepte wie die generische Programmierung kann hier der notwendige Mehraufwand zwar deutlich reduziert werden, dennoch erfordert eine statische Typisierung in der Regel (minimal) mehr Aufwand bei der Entwicklung und kann mitunter umständliche Konstrukte bei sehr dynamischer Datenverarbeitung – beispielsweise im Web-Bereich – erforderlich machen; s. Dynamische Typisierung in C#.

Explizit vs. Implizit

Bei der expliziten Angabe der Typen trägt man als Entwickler Verantwortung dafür, den zum angedachten Inhalt einer Variablen (oder Rückgabe einer Methode) passenden Typen auszuwählen. Bei impliziter Ableitung erledigt dies das Typsystem, indem es den passenden Datentyp zum Inhalt annimmt.

• Explizit: z. B. Ada, C++, C# (standardmäßig), Java
  Beispiele in C++ und C#

  01020304050607

    // C++int age = 27;                      // Ganzzahlstd::string firstName = "Holger";  // Zeichenkette
    // C#int age = 27;                      // Ganzzahlstring firstName = "Holger";       // Zeichenkette

• Implizit: z. B. C# (optional), Haskell, JavaScript, Lua, Prolog, Python, Ruby, PHP, Scheme
  Beispiele in C# und PHP

  01020304050607

    // C#var age = 27;              // Ganzzahlvar firstName = "Holger";  // Zeichenkette
    // PHP$age = 27;                 // Ganzzahl$firstName = "Holger";     // Zeichenkette

Ich bevorzuge hier, sofern die Umstände nicht dagegen sprechen, die explizite Typangabe. Diese bedeutet üblicherweise zwar etwas mehr Schreibaufwand, erhöht aus meiner Sicht jedoch die Verständlichkeit des Quelltextes, da ich die Bezeichner von Variablen ungerne mit Präfixen oder Suffixen versehe, sondern mich bei der Benennung auf den Inhalt bzw. Zweck konzentrieren möchte. Um eine Kleinigkeit zu testen oder für ansonsten sehr umständliche Konstrukte (vgl. generische Programmierung) empfinde ich implizite Typableitung jedoch durchaus komfortabel. Teilweise kann dies sogar notwendig sein; s. Implizite Typisierung in C#.

Stark vs. Schwach

Dieser Aspekt behandelt im erweiterten Sinne die Typsicherheit des Typsystems. Stark typisierte Programmiersprachen erlauben für gewöhnlich – wenn überhaupt – nur implizite Typumwandlungen, sofern kein Datenverlust auftritt (beispielsweise von einem ganzzahligen Datentyp kleineren Wertebereiches zu einem mit größerem Wertebereich). Schwächer typisierte Programmiersprachen sind hier für gewöhnlich "großzügiger".

• Stark: z. B. Ada, C++, C#, Haskell, Java, Python, Scheme
  Beispiele in C#

  01020304050607

  int pi = 3.14;    // Kompilierungsfehler!pi = (int) 3.14;  // 3
  int tmp = 27;if(tmp) {  // Kompilierungsfehler!    Debug.WriteLine("klappt!");}

• Schwach: z. B. JavaScript, Lua, Prolog, Ruby, PHP
  Beispiel in PHP

  0102030405

  $tmp = 27;
  if($tmp) {  // implizite Auswertung als "true"    echo 'klappt!';}  // Ausgabe von "klappt!", da Zahlen ungleich "0" als "true" ausgewertet werden

Ich bevorzuge hier, sofern die Umstände nicht dagegen sprechen, die starke Typisierung. Der Grund ist schlicht der, dass so weitestgehend sichergestellt ist, dass keine unerwarteten oder gar fehlerhaften Konvertierungen vom System vorgenommen werden – sofern ich dem nicht explizit zustimme, wozu die meisten Programmiersprachen entsprechende Typumwandlungen vorsehen. Auch hier ist jedoch zugegebenermaßen üblicherweise ein etwas höherer Aufwand notwendig, als bei eher schwächer typisierten Programmiersprachen.