Zum Hauptinhalt springen
tsecurity.de LIVE
Echtzeit-Radar & Feeds
Alle RSS Feeds
👥 Community & Social
Windows Tipps & SecurityLernen Sie Linux-Befehle mit Webminal direkt im Browser(24.09.2026 um 08:00 Uhr)
Sicherheitslücken (CVE)USN-8811-1: urllib3 vulnerability(24.09.2026 um 03:39 Uhr)
Sichere ProgrammierungYour Agent Has Observability. It Doesn't Have Evals.(24.09.2026 um 07:43 Uhr)
Sichere ProgrammierungProtocol Upgrade Compatibility Review: Robinhood(24.09.2026 um 07:45 Uhr)
Sichere ProgrammierungYour tests share your blind spots. Readers don't.(24.09.2026 um 07:52 Uhr)
Sichere ProgrammierungYour AI agent has more permissions than your users(24.09.2026 um 07:54 Uhr)
Windows Tipps & SecurityLernen Sie Linux-Befehle mit Webminal direkt im Browser(24.09.2026 um 08:00 Uhr)
Sicherheitslücken (CVE)USN-8811-1: urllib3 vulnerability(24.09.2026 um 03:39 Uhr)
Sichere ProgrammierungYour Agent Has Observability. It Doesn't Have Evals.(24.09.2026 um 07:43 Uhr)
Sichere ProgrammierungProtocol Upgrade Compatibility Review: Robinhood(24.09.2026 um 07:45 Uhr)
Sichere ProgrammierungYour tests share your blind spots. Readers don't.(24.09.2026 um 07:52 Uhr)
Sichere ProgrammierungYour AI agent has more permissions than your users(24.09.2026 um 07:54 Uhr)
Intelligence View
⚡ tsecurity.de Intelligence

The Data Engineers Descent Into Datetime Hell

Full Blog Post Here People cannot spell for s***. And datetimes are very difficult to format consistently for various reasons. Date inference is genuinely hard—there's no universal standard, and everyone has their own idea of what "…

0
↗ Quelle (dev.to)
Reagiere als Erste:r — dein Feedback zählt!

Full Blog Post Here



People cannot spell for s***. And datetimes are very difficult to format consistently for various reasons. Date inference is genuinely hard—there's no universal standard, and everyone has their own idea of what "01/02/2023" means (January 2nd or February 1st?). This is my personal battle.



There's a reason this meme is one of the most upvoted posts on r/dataengineering. We've all been there.








The AWS Glue Migration That Wasn't



Here's something I dealt with recently. We were migrating 50+ tables from MySQL to Postgres using AWS Glue. Should be straightforward—Glue's built for this. You set up the connection, map the tables, hit run, grab coffee.



Table #37 fails. Then #41. Then #44.



The error message is useless: ERROR: invalid input syntax for type timestamp. Cool. Which timestamp? Which row? Which of the 47 datetime columns in this table?



You're dealing with 10 million rows. And ONE row—ONE!!!—is causing the entire migration to fail.



You dig into the source data. The created_at column has entries like:




2023-01-15 14:30:00   -- Standard MySQL datetime
01/15/2023 2:30 PM -- Someone's Excel export
January 15, 2023 -- Marketing team entry
2023-1-15 -- Missing zero padding
15-Jan-23 -- European contractor
NULL -- Actually fine
"" -- Empty string (NOT fine)
Q1 2023 -- Why? Just... why?






MySQL doesn't care. It's got loose type coercion. Postgres? Postgres will not accept this nonsense.






PySpark Won't Save You



"Fine," you think. "I'll just use PySpark to clean this first."




from pyspark.sql import SparkSession
from pyspark.sql.types import TimestampType

spark = SparkSession.builder.getOrCreate()
df = spark.read.jdbc(url="jdbc:mysql://...", table="orders")

# Try to cast it
df = df.withColumn("created_at", F.col("created_at").cast(TimestampType()))






PySpark can't infer it. Which is bull****, by the way. It just returns NULL for anything it doesn't understand. No error. No warning. Just silent data loss.



So now you're writing custom parsing logic.






What I Actually Tried






Attempt 1: "Spark's built-in functions will handle this"






from pyspark.sql import functions as F
from pyspark.sql.types import TimestampType

df = df.withColumn("created_at", F.col("created_at").cast(TimestampType()))






Result: 30% of values become NULL. No error. No warning. Just gone.



"Fine, I'll try to_timestamp() with format strings:"




df = df.withColumn("created_at",
F.to_timestamp(F.col("created_at"), "yyyy-MM-dd HH:mm:ss"))






Result: 70% become NULL because they're not in that exact format.



"I'll try multiple formats!"




df = df.withColumn("created_at",
F.coalesce(
F.to_timestamp(F.col("created_at"), "yyyy-MM-dd HH:mm:ss"),
F.to_timestamp(F.col("created_at"), "MM/dd/yyyy"),
F.to_timestamp(F.col("created_at"), "dd/MM/yyyy"),
F.to_timestamp(F.col("created_at"), "yyyy-MM-dd")
))






Now I have 8% NULL. The other 92% parsed! But which format matched which row? No idea. And "January 15, 2023" is still NULL.



Added 12 more formats to the coalesce(). The query plan is now unreadable. Execution time: 45 minutes for 10 million rows.






Attempt 2: "I'll just write a UDF"






from pyspark.sql.functions import udf
from pyspark.sql.types import StringType
from datetime import datetime
import dateutil.parser

@udf(returnType=StringType())
def parse_datetime(value):
if not value:
return None
try:
return dateutil.parser.parse(value).strftime('%Y-%m-%d %H:%M:%S')
except:
return None

df = df.withColumn("created_at", parse_datetime(F.col("created_at")))






Execution time: 6 hours.



Why? Because UDFs serialize every row to Python, parse it, serialize it back. For 10 million rows. On distributed data. The Spark UI shows I'm not even using the cluster, it's all bottlenecked on Python serialization.



"Fine, I'll use pandas UDFs, those are faster:"




from pyspark.sql.functions import pandas_udf
import pandas as pd

@pandas_udf(StringType())
def parse_datetime_pandas(s: pd.Series) -> pd.Series:
return pd.to_datetime(s, errors='coerce').dt.strftime('%Y-%m-%d %H:%M:%S')






Execution time: 2 hours. Better! But still 8% NULL. Still no idea which rows failed or why.






Attempt 3: "I'll do multiple passes with different UDFs"






# Pass 1: Standard formats
df = df.withColumn("created_at_clean", parse_udf_standard(F.col("created_at")))

# Pass 2: Fix nulls with named months
df = df.withColumn("created_at_clean",
F.when(F.col("created_at_clean").isNull(),
parse_udf_named_months(F.col("created_at")))
.otherwise(F.col("created_at_clean")))

# Pass 3: Fix nulls with European formats
df = df.withColumn("created_at_clean",
F.when(F.col("created_at_clean").isNull(),
parse_udf_european(F.col("created_at")))
.otherwise(F.col("created_at_clean")))

# Pass 4: ...you get the idea








  • Execution time: 4 hours (multiple full scans of 10 million rows)


  • Code length: 600 lines across 8 different UDFs


  • Success rate: 99.1%


  • My mental state: Broken






Attempt 4: "Maybe I can use regex_extract?"






# Extract ISO format dates
df = df.withColumn("extracted",
F.regexp_extract(F.col("created_at"), r'(\d{4}-\d{2}-\d{2})', 1))

# Extract MM/DD/YYYY
df = df.withColumn("extracted",
F.when(F.col("extracted") == "",
F.regexp_extract(F.col("created_at"), r'(\d{2})/(\d{2})/(\d{4})', 0))
.otherwise(F.col("extracted")))






This extracted dates but didn't parse them into the right format. 01/15/2023 stayed as 01/15/2023. I need it as 2023-01-15.



Now I need to parse what I extracted. Back to F.to_timestamp(). Back to NULLs.






Attempt 5: "I'll just dump to pandas and fix it there"






# Collect to pandas
pdf = df.toPandas()

# Fix in pandas
pdf['created_at'] = pd.to_datetime(pdf['created_at'], errors='coerce')

# Back to Spark
df = spark.createDataFrame(pdf)






Memory error. 10 million rows don't fit in memory on the driver node. Typical.



"Fine, I'll do it in partitions:"




def fix_partition(iterator):
for pdf in iterator:
pdf['created_at'] = pd.to_datetime(pdf['created_at'], errors='coerce')
yield pdf

df = df.mapInPandas(fix_partition, schema=df.schema)






This works but takes 3 hours and yet still have 8% NULL values.






Attempt 6: The 2AM Abomination






from pyspark.sql.functions import pandas_udf
import pandas as pd
from dateutil import parser
import re

@pandas_udf(StringType())
def parse_datetime_nuclear_option(s: pd.Series) -> pd.Series:
def parse_single(value):
if pd.isna(value) or value == "":
return None

# Try pandas first (fast)
try:
return pd.to_datetime(value).strftime('%Y-%m-%d %H:%M:%S')
except:
pass

# Try dateutil (slow but flexible)
try:
return parser.parse(str(value), fuzzy=True).strftime('%Y-%m-%d %H:%M:%S')
except:
pass

# Try regex extraction for ISO
match = re.search(r'\d{4}-\d{2}-\d{2}', str(value))
if match:
return match.group(0) + ' 00:00:00'

# Try named months
months = {'january': '01', 'jan': '01', 'february': '02', ...}
# ... 40 more lines of string manipulation

# Try quarter notation
if 'Q' in str(value):
# ... 20 more lines

return None

return s.apply(parse_single)






This is so frustrating. Just kill me.




df = df.withColumn("created_at", parse_datetime_nuclear_option(F.col("created_at")))








  • Execution time: 8 hours


  • Code length: 200 lines in a single UDF


  • Success rate: 99.4%


  • The remaining 0.6%: Truly cursed data like "FY Q3 2023", "sometime in january", and my personal favorite: "2023-13-45" (month 13, day 45—someone just mashing numbers)


  • Cost: $47 in AWS Glue DPU hours



At this point it's 4am. The migration is still failing. I have a 200-line UDF that takes 8 hours to run and still doesn't work for all rows. And I still have 12 other tables with datetime columns to fix.



Read the rest at Full Blog Post Here

SOC Incident Playbook: Remote Code Execution (RCE) Defense
title: Detect Exploitation - The Data Engineers Descent Into Datetime Hell
id: 459f8e92-68be-436d-baa8-ab25b6d9bb90
status: experimental
description: Automatisch generierte SIEM-Erkennungsregel basierend auf CTI Intelligence
references:
  - https://tsecurity.de/
author: iShareStuff CTI Automated Detection Engine
date: 2026-09-24
logsource:
  category: network_connection
  product: any
detection:
  selection:
      CommandLine|contains:
        - 'exploit'
  condition: selection
falsepositives:
  - Legitime administrative Zugriffe oder Penetrationstests
level: high
tags:
  - attack.initial_access
rule CTI_Threat_Indicator {
    meta:
        author = "iShareStuff CTI Automated Detection Engine"
        date = "2026-09-24"
        description = "YARA Signature for "
    strings:
        $str = "The Data Engineers Descent Int" ascii wide
    condition:
        any of them
}
tsecurity.de Cognitive Threat RAG
Fokus-Vektor:

Kognitive Analyse für identifizierte Bedrohung: Erhöhte Bedrohungslage im Bereich The Data Engineers Descent Into Datetime.... Basierend auf 368k Vektor-Korrelationen werden sofortige Isolationsmaßnahmen für betroffene Endpunkte empfohlen.

🛡️ Angriffsfläche & Exposure

Netzwerk/Remote-Zugriff ohne Vorauthentifizierung möglich.

Empfohlene Sofortmaßnahmen
  • 1. Perimeter-Inspektion: Relevante Portfreigaben und exponierte Endpunkte unverzüglich scannen.
  • 2. Patch-Applikation: Hersteller-Hotfix einspielen oder betroffene Daemons in isolierte DMZ-Segmente überführen.
  • 3. Telemetrie & EDR-Alerts: Prozessaufrufe und Child-Processes auf anomale Shell-Spawns überwachen.
🔗 Semantisch verwandte Zero-Days MariaDB 11.7 VEC
Ähnliche Beiträge
🔍 Verwandte News

Auch interessante Nachrichten The Data Engineers Descent Into Datetime Hell

Thematisch verwandte Begriffe: Data, Engineers, Descent, Into · 6 Treffer

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Zum Aktualisieren ziehen
ZERO-DAY CVE-2026-96676 | A vulnerability was identified in Fast FAC1900R 20190827_2.0.2. The impa…
Advisory →
TTS Reader • tsecurity.de Voice
tsecurity.de Icon
tsecurity.de App
Offline-Lesen, Eilmeldungen & 0ms Ladezeit

Installiere tsecurity.de direkt auf deinen Home-Bildschirm für das ultimative Vollbild-Magazinerlebnis ohne Browser-Leisten.

Nächster Beitrag
Themen-Radar & Intelligence Matrix
Echtzeit-Taxonomie nach Angriffsvektoren & Plattformen

tsecurity.de Live Threat Radar

🔴 LIVE RADAR
MONITORING
AKTIV
CVE-DATENBANK
LIVE
🔍
Community Radar & Live Chat
Sentinel Bot online • Live-Stream
Dein Cluster: Security Explorer
Match:
lädt…
Verbindung zum Community-Stream wird aufgebaut...
Bearbeitungsmodus — Senden überschreibt deine Nachricht
Community-Puls — was gerade passiert
lädt…
Aktivitäten deiner Analysten
lädt…
Neues Thema oder Eilmeldung einreichen

Reiche interessante Links, Zero-Days oder Debatten ein. Die Community entscheidet per Upvote über die Veröffentlichung.

Heiß diskutierte Einreichungen
🔖 Gespeicherte Artikel
📂 Keine gespeicherten Artikel vorhanden.
Zurück Ziehen Vor
Links: vorheriger Artikel Rechts: nächster Artikel unten: schließen
News NIS-2 Frühwarnung Tier-1 Intel TTP ⏱️ 3 Min vor 10 Min
Artikeldaten werden geladen...

Zurück: vorheriger Vor: nächster
↗ Original-Quelle
Social Reaktionen Deine Reaktion zählt
Einstufung & Relevanz-Poll 0 Stimmen
In sozialen Netzwerken teilen 1-Klick