Is there a section in the documentation about how ...
# ask-community
Is there a section in the documentation about how the
argument is used when declaring a partition (i.e.: here)? There’s this about schedules, but it doesn’t mention anything about materializing an asset. Specifically, I’m wondering how it interacts with the Dagster materialization UI and its own Timezone setting. I’m also wondering about what it may mean for an IO manager that needs to read/write partition string representation in a filename or path.
Timezones are everyone’s favourite topic! I was pleased to see that Dagster doesn’t ignore this problem. But I also cannot find a lot of details around what it means to set that value. I’m also curious to understand what it means to set it on a daily partition definition. How would it be used in this context?
so the timezone setting in dagit just affects what timezone various timestamps for execution display as, and doesn’t affect the partitions for an asset. IE, when you choose a partition to execute, it’s not based on the timestamp you set in the UI, but the timestamp that you set when defining the partitions
this is definitely confusing, and warrants better documentation
Ok, what I would really like to have is the ability to tell dagster about the “local time” of an asset. We have multiple data sources in different timezones that we’d like to harmonize into
. So ideally, we’d be able to specify partitions in any of the following 3 timezones and dagster would just “get it right”: • the asset’s local timezone (e.g.:
) • the browser’s (user’s) timezone (e.g.:
) •
It’s generally a lot easier to think in the asset’s “local timezone”, but making this choice explicit makes it a lot easier to understand what’s going to happen. e.g.: if I ask for partition
which one of those 3 possible timestamps am I referring to? Lastly, when writing the partition out to disk, I’d like to use
timestamps so we don’t have to deal with daylight savings shenanigans. Also, I haven’t thought this through entirely, but I think we can ignore timezones for any partitioning that’s coarser than hourly