Add ability to ignore timezone for a date subfield

So you want a setting that preserves the saved timezone from the initial value? I'm not exactly sure how this would work for second user when viewing the field value. I guess I'm not exactly sure if they changed the value how they would know what timezone they are working in.

Should there maybe be some sort of timezone selector as part of the date widget that in your example would allow PM to set timezone to Berlin time and thus saved value is reflected that way? I think something is doable here, i just would have to understand the workflow and visual expectations for each user involved in different timezones.

Well, to implement ability to add "optional" timezone converter using timezones or using php

print_r(DateTimeZone::listIdentifiers());

would be really nice. The same as currently module smart_date → does.

so user can optionally select also timezone and it will be converted to UTC as always in database. That would be really nice feature and as you suggested if enginer is in Berlin, or in Paris, PM can select his timezone.

I think this is doable by an optional setting in the widget that would add a timezone select field. The value wouldn't be saved in the db but would be used to just modify the stored datetime presave. I'll see what I can do to make this work.

Thank you, much appreciated.

I'm getting back into this and still I guess trying to wrap my mind around what you need here. Are both you as project manager and the engineer setting the value to the same field or are you as project manager trying to set the date value on behalf of the engineer in his timezone? If the latter, I'm guessing you would just want a timezone select with no default value since it wouldn't be saved but you would choose his timezone on save and the actual date saved would be in his timezone but value shown to you would be in your timezone? I'm just confused as to what date you would expect to see next time you edit? Sorry, I'm just really confused with how this would work.

However when I add date "18-June-2025 at 21:00" it stores it in database as "18-June-2025 at 11:30" UTC and reports shows that engineer completed task before it was scheduled.

With this scenario, assuming you enter the date "18-June-2025 at 21:00" and were able to set the timezone to berlin, what value would you expect to see in the widget next time you edit. I think it would be 18-June-2025 at 13:00 which in US (1:00 PM)? I just don't even know if this would make any sense at all unless we create a completely new field type that actually stores the timezone so maybe then the stored datetime value is always reflected in the widget as the value with the set timezone. And in this case, I would assume you would also need the formatters modified for this option as well but they are currently generic to regular datetime fields so just not really sure how to even accommodate this.

My expectation was to have two fields:
1. A datetime field
2. A timezone selectioN

You would choose their timezone on save, and the actual date saved would be in their timezone, but the value shown to you would be in your timezone?

No, I want to see it always in their timezone because the change was made there, and it is their local time. I don’t care about my US time. For example, an engineer will call me to say the job is done at 9:00 PM local Berlin time, and I would like to add 9:00 PM to the system. However, currently, the system recalculates it to my profile’s timezone and stores it as 11:30 AM UTC, which is 1:30 PM in my timezone, not the reported 9:00 PM.
It would be nice to have a timezone selection that ignores my profile’s timezone. So, if I add 9:00 PM and select Berlin/Germany, it will store 7:00 PM UTC in the database.
You’re probably right—it’s better to create a new subfield type instead of modifying the default “date” type with a widget only.

Okay, i think i understand.

1. Create an update hook that adds a 'timezone' column to the datetime subfield OR possibly just create a new field type since datetime type = 'date' would be irrelevant.
2. Add a timezone form element to the widget.
   1. Settings for whether to show timezone in form?
   2. Settings to make it required if a value is set?
   3. Should it be permissioned? Example: If you as admin set a timezone value, should other user ALWAYS be allowed to override it to some other value?
   4. Settings to filter the timezone options? Maybe you want to make it simple and just have a couple relevant timezones to select from?
3. The datetime form default value would look the same (e.g. not converted) but the actual value rendered in the formatters could be in timezone specified.
   1. Assuming we should add multiple options here for output of which timezone to display the date in. Site timezone, user timezone, new timezone value on date field?
   2. Views stuff may need to remain the same perhaps for now at least at least for sorting, not sure how multiple values in different timezones would work?
   3. Seems like the "VIEWS option for both berlin and utc time" maybe should just be handled in the sub-field formatter so its used everywhere as an option?

There's a long running issue around this type functionality that has seemed to have just gone off the rails. We don't need to do anything complex here with messing with existing date values... will keep it simple: https://www.drupal.org/project/drupal/issues/2716891 🐛 DateTimeIso8601::setDateTime() vs. DateTimeItem::schema(): (at least) one of them is broken Needs work

Settings for whether to show timezone in form?

I guess so.

Settings to make it required if a value is set?

Well maybe add ability in form display to add default value - like UTC preselected by default? And if no default value is configured - yes required field would do the trick.

Should it be permissioned? Example: If you as admin set a timezone value, should other user ALWAYS be allowed to override it to some other value?

Well we (PMs) have backups and of course there can be a mistake so any backup or "Regional Lead" should be able to change it if needed so at least "role" based would be nice.

Settings to filter the timezone options? Maybe you want to make it simple and just have a couple relevant timezones to select from?

That would be really nice feature as currently we work in severals countries only and do not need to see list options of all timezones. So sort of "multiselect list in form display mode" would be really helpfull so we can select like 20 to show for our PMS and if needed later we can add more in settings.

Assuming we should add multiple options here for output of which timezone to display the date in. Site timezone, user timezone, new timezone value on date field?
Views stuff may need to remain the same perhaps for now at least at least for sorting, not sure how multiple values in different timezones would work?

Well smart date works in similiar way, unable to display the date in both timezones at the same time but in views you can add the same field twice (multiple times) and for every field choose diferent timezone to display - site timezone, or or user timezone and of course that selected one and also there is option to display in UTC.

Hope it helps. Much apprciated your time and effort:)

@coaston,

I'm working on this for you but it would be really helpful if you would join the #custom-field slack channel to correspond. Can you do that?

Join the Drupal #custom-field slack channel.

Thank you.
i am in, but will be limited due to vacation time.

Thank you!

I tested it and it works as expected :

However the Display mode formatter it seems only works for the "default". When I change to table or flipped table it does not save it. {nothing in logs}. The same "issue" when I tried with Views - only the default formatter works as shown here: Formatter.mp4 →

Oh i see, the formatter settings aren't being saved for some reason. Okay let me see whats going on there and I'll followup back up.

@coaston, I just committed a fix for settings not saving.

The fix for the formatter settings was minor and I was able to reproduce the issue myself and verify settings are saving for both formatters so calling this good and merging it!