What is the purpose of these potentially redundant timezone fields?

Tim_Rohrer · 2023-09-16T14:56:57.986Z

In a View I’m developing, my aggregation includes:

        $addFields: {
          adjustedUTC: {
            $dateFromParts: {
              year: {
                $year: {
                  date: new Date(),
                  timezone: "$timezone",
                },
              },
              month: {
                $month: {
                  date: new Date(),
                  timezone: "$timezone",
                },
              },
              day: {
                $dayOfMonth: {
                  date: new Date(),
                  timezone: "$timezone",
                },
              },
              hour: {
                $hour: {
                  date: "$startDateUTC",
                  timezone: "$timezone",
                },
              },
              minute: {
                $minute: {
                  date: "$startDateUTC",
                  timezone: "$timezone",
                },
              },
              timezone: "$timezone",
            },
          },
 }

The adjustedUTC field is set by a $dateFromParts expression that needs to account for the timezone of the event data. This code is doing what I want, but all of the setting of timezone fields seems redundant when I set it for the entire $dateFromParts expression and each part field. I thought I should be able to remove the latter entries, but then the code fails. Likewise, if I remove the option for the entire $dateFromParts expression, the logic fails.

What is the difference between these timezone options that makes all of them required?

And second, I’d welcome other ideas to simplify the creation of adjustedUTC. It does need to account for both the current date and the time contained in $startDateUTC.

John_Sewell · 2023-09-16T16:07:29.304Z

So you’re creating a new date, based off the current year, month and day, but the hours and minutes come from what you pass in within $startDateUTC?

That looks suspiciously like you could have an edge case on the scenario when you cross a date boundary if the current time is say 10am but the startDateUTC is at 11pm.

Tim_Rohrer · 2023-09-16T19:23:46.391Z

The data is of recurring events that are only captured by weekday, local time, and timezone. This creates problems when regions (aka, timezones) change between DST and standard time.

The adjustedUTC is reflects the current UTC time of the event based on $$NOW as the date, and the original time reflected in startDateUTC, thus accounting for DST in the subject timezone.

I just don’t understand why every particular field and the overall dateFromParts expression requires the timezone to be set.