the unofficial Zulu format is not treated as Zulu if the timezone is present...

[pleasantone]

I just want to be clear, this isn't a bug report per-se, more an observation.

You describe an unofficial date time format, "YYYY-MM-DDTHH:mmZ" and I note in particular that the "Z" is part of the format. If a timezone attribute is present, the timezone overrides Zulu instead of Zulu overriding the timezone. I was hoping I could feed atcb an event in UTC, but have ATCB convert it to the optimal format for the user/event.

The scenario I am thinking of is calendar entries are maintained in UTC, and a local-ish timezone is used to convert that UTC to the proper timezone.

I know I keep harping on timezones, and if I'm being a pain in the a--, just let me know and I'll stop with it and just hack my own code, I'm just in love with yours, you did a great job.

Why is this even interesting? If your ICS timezone matches (e.g. America/Los_Angeles) then apps like iCal and Fantastical will simply display the time cleanly. If your ICS entry timezone doesn't match, then they tend to display the event in local time and again in the time of the originating event's timezone.

I think it fundamentally comes down to the possibility that there are two types of event datetimes we want to deal with, and atcb only thinks about one. The first is the fixed time an event occurs (i.e. 2001-12-25T15:30Z is UTC) so we ensure the event starts at the right time for the all users no matter where they are, and one that is the user friendly time (e.g. 2012-12-25 7:30am America/Los_Angeles (assuming -8 for standard time at the start of the time)) that would go in an .ics file (or, for that matter, a date format atcb button).

[jekuer]

First: Every feedback is welcome!! 🤗

Second: I don't get it, unfortunately.

Could you maybe describe it in a more precise way - like what you want to do - while not mixing up multiple things?
Regarding your entry point: That's how it should work: You define an event. And this event can be UTC or within a time zone you define. And yes, if you define a time zone, it overrides UTC. I would argue this is the ideal developer UX.
Why would you define a time zone, that should have no effect? That's where I don't get it.

"The scenario I am thinking of is calendar entries are maintained in UTC, and a local-ish timezone is used to convert that UTC to the proper timezone."
-> That's exactly the case, if we think time and events as something fixed.

It feels like what you are describing is more about the visualization of a time, right?
Basically what you can achieve when using the "magic" time zone currentBrowser.

This would mean that you want to define a time without any time zone, which also never gets converted on a UI level and gets converted to the user's time zone when saving - so it is still the same in his calendar. Basically that 8am is always 8am - no matter if the user is looking at the date button or saving the event. Correct?

[pleasantone]

First my apologies for the delay responding, I've been absolutely slammed.

It is/isn't a display issue, again dropping the whole date-button thing from my previous comments...it's a question of how an event is displayed in their calendar. The vast majority of my experience is working with iCal format, so I can't say I'm an expert at Outlook or some of the others.

Using the following jsfiddle, if I create an add-to-calendar button with the calendar entry entered in UTC, the .ics file that is created has the event in UTC, seems great... and it displays as:

Whereas the same event entered in UTC is:

Notice it shows up in the same place in the calendar, but the entry itself actually says 6:15pm UTC.

That's confusing to users.

I had the idea of specifying the event in UTC, so it always starts at the right time, but I'd like to make use of the current browser's timezone when generating the ICS file to make things a bit more user-friendly.

Please take a look at the fiddle, I put up those examples, and then went crazy with the date button as well, despite the date button being a separate issue, just because it displays the examples easier than if you look at the ICS files with a text editor or load them into a Calendar program.

[jekuer]

Alright. I see.
Your request, in the end, is about having an option like "transformToUserTimeZone", where a date gets transformed to a users time zone with both, datetime and the time zone itself. Basically, what we do with the mentioned magic keywords at the location, but extended to the actual event which gets saved to the calendar (not only the button UI).
I put it on the list.

For the moment, some information why we did not add it so far:
There is a reason for working with time zones! It is the time zones 😉. Manipulating them can be easily confusing!
Case 1: People are used to time zones. Imagine 2 people planning an event. 1 is located in SF, 1 in NY. They both save the event. Even if technically correct, they would be like "yeah, but this is east coast time - you need to adjust." "No you." "No you".
Case 2: You are based in SF and plan to visit Atlanta. You book a zoo ticket and save the event. You travel to Atlanta. Your calendar shows the Pacific time zone next to the event. You would be wondering whether this is correct, as you are EST now, while the event is also EST. Did you save the event correctly?
Case 3: It can be sometimes hard to find out which time zone to transfer it to (from the script's perspective). For example, while traveling, your calendar may have a different time zone than your browser, leading to strange edge cases. Not wrong dates, but irritating situations.

Bottom line: a correct explicit time zone always comes with less potential for misunderstandings.
Therefore, the default and best practice always should be to have a time zone matching the event's location. Going to the Atlanta Zoo at EST is obvious and easily understandable.
However, there are cases, like online events, where this does not apply.

[jekuer]

Forgot to mention that this went live with version 2.6 🥳.

Called it useUserTZ.

[pleasantone]

Outstanding, will test next week.

[pleasantone]

Just tested, works great, thank you!!!