Open MartinBernstorff opened 4 months ago
Hey @MartinBernstorff,
Thanks for the submission and sorry for the late reply.
Yeah, I'd consider that a bug. GCSA follows the official API that supports both timezone in datetime (formatted according to RFC3339) and explicit timezone field. So I'd keep the timezone argument (so user can pass naive datetime with explicit timezone
).
But I'll need to fix for timezone aware datetimes case.
Thanks again for finding this.
No worries at all, I'm super happy about GCSA and the tremendous amount of effort you've put into a nice open source library!
Out of interest, what would happen if the timezone field and the timezone information in the start or end fields do not match? It seems like an invalid state, so perhaps raise an error on construction/mutation?
Firstly, thanks a ton for your work here, the library is a pleasure to work with!
Currently, the
.start
and.end
attributes support datetimes, which can include timezone information. I tried to use that to set timezone, but when creating an event, that information is ignored, instead using the string from the.timezone
attribute.I suggest dropping the
.timezone
attribute, instead enforcing that the timezone of.start
and.end
is the same, and adding a.timezone
property, which returns a string based on the tzinfo of.start
.