# Suspension Time Frames Incorrect
**URL:** https://meta.discourse.org/t/suspension-time-frames-incorrect/179339
**Category:** UX
**Created:** [February 11, 2021, 1:54pm UTC](https://meta.discourse.org/t/suspension-time-frames-incorrect/179339 "2021-02-11T13:54:36Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@CaptainZac](https://meta.discourse.org/u/CaptainZac)
#### Post date: [February 11, 2021, 1:54pm UTC](https://meta.discourse.org/t/suspension-time-frames-incorrect/179339/1 "2021-02-11T13:54:36Z")
It appears here that all of these days should actually be in a month, that would make all of these date [Month] 11th since it is February 11. If I want to suspend for exactly a month, I have to instead go to the calendar and select. Is there a way to change this so it would be exactly a month away?
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [February 12, 2021, 12:58am UTC](https://meta.discourse.org/t/suspension-time-frames-incorrect/179339/2 "2021-02-12T00:58:27Z")
I re-categorized this to the UX category. I don’t think that it’s technically a bug. Your point is a good one though. I notice that when I select a time frame for a bookmark, the Next Month option returns March 11 (for today), instead of returning March 1 for next month as is shown in the suspend modal.
---
### Author:  [@CaptainZac](https://meta.discourse.org/u/CaptainZac)
#### Post date: [February 13, 2021, 4:54am UTC](https://meta.discourse.org/t/suspension-time-frames-incorrect/179339/3 "2021-02-13T04:54:16Z")
Is there anyway the developers are able to change it so it runs off the same system as the bookmarks in regards for dates?
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [February 13, 2021, 4:57am UTC](https://meta.discourse.org/t/suspension-time-frames-incorrect/179339/4 "2021-02-13T04:57:57Z")
Maybe, let’s ask @martin next week to take a peek.
---
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [February 14, 2021, 10:46pm UTC](https://meta.discourse.org/t/suspension-time-frames-incorrect/179339/5 "2021-02-14T22:46:27Z")
This is a little bit tricky because I made a new component for bookmarks and topic timers to use, which has time presets slightly different to these dropdown components. I will take a look and see if I can somehow make just the time part consistent between the two. We don’t want the big list design that is in the bookmark/timer modal in places like this (I don’t think).
---
### Author:  [@andrei](https://meta.discourse.org/u/andrei)
#### Post date: [June 16, 2021, 11:41am UTC](https://meta.discourse.org/t/suspension-time-frames-incorrect/179339/8 "2021-06-16T11:41:32Z")
Turns out that recently we accidentally introduced a new behaviour of date-pickers on:
- the bookmark modal
- the topic timers modal
In fact, all other date-pickers always choose **the first day of the next month** when picking the `Next Month` option. This is the default behaviour. The ability to choose a day exactly in one month from today is important too, but it isn’t among our defaults, so the calendar should be used for doing this.
So we won’t change the behaviour of the suspension modal, moreover, we returned the pickers on the bookmark modal and the topic timer modal to our defaults in this PR:
[https://github.com/discourse/discourse/pull/13365](https://github.com/discourse/discourse/pull/13365)
See also:
> [@Weirdness in dates when setting timeout for an invite link](https://meta.discourse.org/t/weirdness-in-dates-when-setting-timeout-for-an-invite-link/191917/9):
>
> You have to look at the original intent, which was Google GMail: I think we kinda lost sight of the goal somewhere along the way, but you can see this is very “next time interval” oriented, as in: When the next day starts (tomorrow) In the middle of the coming week When the weekend starts When the next week starts That was always my intent, and I tried to be quite clear about this, but I think we played a game of “telephone” and stuff got garbled in translation along the way, someh…