As the minimum requirement for 3.1 is php 5.2 we should do something on this. Switching from DST on to off and back again is quite stupid.
What I also would like to have is a function, which gives back the UTC timestamp from a date+time the user specified with his timezone/dst-settings.
Timezone DST Handling in 3.1
Forum rules
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.3.x. If you need support for phpBB 3.3.x please visit the 3.3.x Support Forum on phpbb.com.
If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.3.x. If you need support for phpBB 3.3.x please visit the 3.3.x Support Forum on phpbb.com.
If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
- nickvergessen
- Former Team Member
- Posts: 733
- Joined: Sun Oct 07, 2007 11:54 am
- Location: Stuttgart, Germany
- Contact:
Timezone DST Handling in 3.1
Member of the Development-Team — No Support via PM
- A_Jelly_Doughnut
- Registered User
- Posts: 1780
- Joined: Wed Jun 04, 2003 4:23 pm
Re: Timezone DST Handling in 3.1
I don't see any reason why user::format_date() couldn't be modified for this. I agree, the date/time framework of PHP >= 5.2 would be good to use.
A_Jelly_Doughnut
Re: Timezone DST Handling in 3.1
Option 1: http://www.phpbb.com/community/viewtopi ... &t=1020905
Option 2: http://www.phpbb.com/community/viewtopi ... &t=1988855
The biggest challenges in my mind are:
1. Conversion from existing utc + dst offsets to timezone name is not unique.
2. Timezone names are not localized. (?) <-- I suspect this issue may be solved with scripting some creative google/dictionary searches.
Option 2: http://www.phpbb.com/community/viewtopi ... &t=1988855
The biggest challenges in my mind are:
1. Conversion from existing utc + dst offsets to timezone name is not unique.
2. Timezone names are not localized. (?) <-- I suspect this issue may be solved with scripting some creative google/dictionary searches.
- nickvergessen
- Former Team Member
- Posts: 733
- Joined: Sun Oct 07, 2007 11:54 am
- Location: Stuttgart, Germany
- Contact:
Re: Timezone DST Handling in 3.1
The MOD does nearly the same thing I'm suggesting here, it just uses a hackish way to do sonn- wrote:Option 1: http://www.phpbb.com/community/viewtopi ... &t=1020905
altough this would only help on little percentage of the boards, you could try timezone + selected language, and if you don't know it with that information, you could just select one with the correct setting.nn- wrote:Conversion from existing utc + dst offsets to timezone name is not unique.
We also translate the days/months etc, to get a localised version of them, when using format_date, so that shouldn't be a big problem:nn- wrote:Timezone names are not localized. (?) <-- I suspect this issue may be solved with scripting some creative google/dictionary searches.
Code: Select all
'Sunday' => 'Sunday',
'Monday' => 'Monday',
'Tuesday' => 'Tuesday',
'Wednesday' => 'Wednesday',
'Thursday' => 'Thursday',
'Friday' => 'Friday',
'Saturday' => 'Saturday',
Member of the Development-Team — No Support via PM
Re: Timezone DST Handling in 3.1
This is something I'd like to pick up.
You can just convert to the Etc/GMT±x backwards compatible timezones.nn- wrote:1. Conversion from existing utc + dst offsets to timezone name is not unique.
Re: Timezone DST Handling in 3.1
This is an interesting idea but I don't think it's working:ToonArmy wrote:You can just convert to the Etc/GMT±x backwards compatible timezones.
https://gist.github.com/a9eb66fbb44f3c2d9554
Code: Select all
America/New_York
2010-04-16 04-18-05
Etc/GMT-5
2010-04-16 13-18-05
Etc/GMT
2010-04-16 08-18-05
UTC
2010-04-16 08-18-05
Fri Apr 16 04:18:05 EDT 2010
Then, GMT-5 seems to literally mean -5 (or +5, as the case may be). For EST+DST you'd have to use GMT-4, which is 1) (somewhat?) incorrect and 2) will break once DST ends. Although I suppose admins may mass PM users to set their timezone after the upgrade, which would only leave inactive users with wrong timezones.
My transition idea involved keeping utc offset + dst offset around until users went to ucp and changed timezone. It has the same problem of breaking once dst begins or ends, has the advantage that utc offset always corresponds to the user's timezone, and has the disadvantage of requiring more code and 'dual-use' db columns.
An option is hacking Etc/GMT+-X until they return correct results, but not displaying these timezones in ucp. Instead, if a user is in 'legacy' timezone, on top of timezone selector there would be a note explaining the situation and asking the user to select correct timezone. Maybe some users won't appreciate being forced to enter a timezone when they are in ucp for some other reason.