Add timezone to expiry field

[sphh]

Summary

When entering an expiry date, this date is shown in the timezone of locale #2882

1. If you want to add an expiry date in a different timezone than your locale, you have to do the calculations yourself.

2. If you change the timezone of your computer, because you move to a different place, the time displayed changes, because the time stored in the database are in UTC. Sometimes you need the expiry date in a different timezone (think credit cards, passports, ...). A way to display the expiry date in a different timezone would be helpful in avoiding errors when entering expiry dates into websites.

Desired Behavior

With regard to

1. A way to change the timezone of the expiry date would be helpful.

2. A way to display the expiry date in a different timezone would be helpful.

Possible Solution

With regard to

1. Add a timezone selector beside the entry box for the expiry date.

2. Add an option specific to each entry which decides in which timezone the expiry date should be displayed. I can think of a couple of options how the expiry date is displayed in the General tab: a. The expiry date is displayed in the timezone, in which the expiry date was saved. b. The expiry date is displayed as in a. beside the expiry date in the locale's timezone. c. There is a toggle to switch between those two displays.

Context

With regard to

1. You have a credit card from a different timezone, which expires at midnight, you have to do the maths yourself to enter the correct expiry date.

2. You have a credit card (or passport), which expiry date is in a different timezone. On a website you have to enter the expiry date of the timezone, the credit card's was issued in. Currently it shows the expiry date to the current locale.

[droidmonkey]

This seems like a fair amount of work, and added complexity to the entry editing, for little gain. Does it matter if you are off by 1 or 2 hours for a credit card or passport?

[droidmonkey]

To be honest, the lowest unit in the expiration field should be days, not hours/minutes/seconds. None of our presets take into account the time, mainly because it is irrelevant.

[sphh]

Sorry, yes it does. For the sake of argument, consider that you are living in a country which has daylight saving time (aka summertime). In December (no DST), you enter an expiry date of December 31st, 23.59 for your credit card. In June (now DST applies), you have to enter this expiry date. It will show up at January 1st, 00.59, so a day later (if you just look at the date). If you are lucky, your credit card will be rejected and you notice the error, correct it and pay for your holiday. If you are unlucky, you are rejected at the airport and cannot board your flight, because the expiry date of you passport differs from the expiry date you entered on the airline's website.

And yes, the time is mostly irrelevant, in this case. Still it should show the expiry date in the right

[droidmonkey]

Yes I agree if you are using the expiration date for form entry then it does matter. I think it would be appropriate to always show the UTC time thereby overcoming the entire issue because no conversions will take place based on locale.

[sphh]

Yes, that would solve the credit card/passport issue.

But when will an entry with an expiry date be crossed out (and disappear from the list of entries if thus configured)?

Consider the following case: You live somewhere in the States where your time difference to UTC is 7 hours. You have entered a date of 30th June 2022, 23:59 UTC for the expiry data for your credit card (because it is valid until 06/22), so that the date shown in UTC time is always correct. This entry will automatically be made expired at 30th June 2022, 23:59 UTC and will disappear from the list, but your local time is still 30th June 2022, 16:59 and your credit card should still be valid.

Whoever invented timezones was definitely not aware of the complications in a global world. ;-)

[droidmonkey]

Timezones are very necessary for human psychology. I will just put "UTC" after the expiry field. It expires when the clock strokes the date and time indicated at UTC. 99% of users won't notice or care about the difference.

[sphh]

Yes, they are very necessary indeed. And as the human psychology they are complicated.

I myself would have preferred two fields with timezone pickers beside the input field for the expiry date: Timezone of expiry date and Timezone for display. Both will default to locale, so 99% of the user's won't experience any difference. The other 1% (I am surprised, that these are only one percent...) could adjust the date to their liking.

I believe Thunderbird's Lightning calendar add-on has a good timezone picker when adding a new event (when enabled):

It shows the timezone as a clickable text. If it is clicked, a dropdown menu opens showing only the timezones used so far. An additional item to select a new timezone is displayed underneath.

Only display date (no time) could be another useful checkbox...

[mnpenner]

+1. An online store kept rejecting my credit card. Turns out it was because I was entering the expiration date wrong!

I had set to expire at 2022-04-30 11:59PM to denote it expires 2022-04, but then on the bottom pane when previewing an entry it was showing 2022-05 because it was adding 7 hours for my timezone.

I don't actually care what timezone KeePass uses, but I think it's important that both the preview pane and entry editor use the same timezone.

[sphh]

Your proposal would only work, if the record were not automatically deactivation, which is the whole purpose of the Expiry date. Maybe I should start using the Notes field to store the expiration date (a special field would also be possible, but that is not shown in the main tab ...)

I still believe, that the expiration date should have a time zone attached, which is imporant for internal purposes (such as marking it as expired at the right time). It should be able to specify a second time zone for display purposes (which can be local - the default - or the time zone of the issuing country of the credit card)...