How to extract year/hour from datetime fields in GROQ queries?

Unfortunately, GROQ doesn't support JavaScript-style methods like getFullYear(), getMonth(), or getHours() directly on datetime values. The dateTime() function is mainly for converting strings to datetime objects for comparisons and ordering, not for extracting date components.

However, you have a couple of options:

Option 1: String manipulation with string::split()

Since datetime fields are stored in ISO 8601 format (like 2024-03-15T14:30:00Z), you can use GROQ's string functions to extract parts:

*[_type == "open_course" && is_active == true]{
  in_person{
    'year': string::split(start_date, '-')[0],
    'month': string::split(start_date, '-')[1],
    'day': string::split(string::split(start_date, 'T')[0], '-')[2],
    'hour': string::split(string::split(start_date, 'T')[1], ':')[0]
  }
}

This works by splitting the ISO datetime string on delimiters like -, T, and : to extract the components. You can also use substr() if you prefer working with string positions.

Option 2: Process after retrieval (recommended)

The more practical approach is to handle this in your application code after fetching from Sanity. This gives you full access to JavaScript's Date methods and is generally cleaner:

const data = await client.fetch(`
  *[_type == "open_course" && is_active == true]{
    in_person{
      start_date
    }
  }
`);

const processed = data.map(course => ({
  ...course,
  in_person: {
    ...course.in_person,
    year: new Date(course.in_person.start_date).getFullYear(),
    month: new Date(course.in_person.start_date).getMonth() + 1,
    day: new Date(course.in_person.start_date).getDate(),
    hour: new Date(course.in_person.start_date).getHours()
  }
}));

The string manipulation approach works in a pinch, but processing in your application code is typically more maintainable and gives you better control over formatting and timezone handling. GROQ is designed to be a query language rather than a full data transformation layer, so it's perfectly normal to do this kind of processing client-side.