When creating a new scheduled fireteam here on Bungie.net it's unclear whether you're asking me for UTC or local time, and when you're displaying you can't omit the timezone either. A date without a timezone is practically meaningless. Start by displaying the date's timezone to make things less confusing. Then try to fix this nonsense. When the fireteam is created a -9h offset is applied to the [b]displayed[/b] date, which is now shown as 2019-12-26T07:20:00. I don't think your webserver is in Alaska, therefore I kept investigating. Looking at the source of the printed out date, I can see you're actually outputting two values: - in the HTML tag's attribute: 2019-12-26T15:20 (this is [i]almost[/i] my original date, which was correctly shifted from GMT+1 to UTC) - in the HTML tag's visible text: 2019-12-26T07:20 (this is garbage to me.) I can immediately notice two problems here. Firstly, you're treating my initial input as LOCAL TIME (GMT+1) which is causing the -1h offset upon save (i.e. your database record likely stores my time in UTC, and I bet you didn't store the timezone or the -1h offset separately.) The second problem is that you're printing out the UTC date in the HTML but displaying that same date to the user in PST (UTC-8h) time. This is an indication that you're printing out the local date in the same timezone as your webserver instead of UTC or my local time, which would make the most sense. Let's disregard Daylight Savings, "storage vs usage relativity" (e.g. scheduling an event before DST starts or ends,) and changes in webserver configuration for a moment and let's see what possible simple fixes there are. First option I'd consider is outputting the UTC time to the page and offloading local time correction to the browser, perhaps using HTML5's new TIME element. This should be the easiest strategy to ensure everyone sees the correct time for their location (I surmise this is what you wanted, but failed, to do.) Alternatively, you should keep track of the time offset that exists between my literal input (i.e. what I wrote in the INPUT element) and the interpreted input (i.e. the DateTime object you created from the literal input) and store this value along with the date in your database. This gives you a way to display the time in my original local time, which is fine so long you show the offset/timezone along with the date for all the other poor guardians who don't necessarily know my timezone. Final option, is to treat everything as UTC and pay attention to avoid time shifts caused by the webserver's own timezone. However, this is the option I like the least because guardians aren't aviators, as such Zulu time it'll probably just inconvenience them.