local time zones

You can get the client computer’s time zone offset via JavaScript. You could use it to adjust the times shown to end users on your site. Themes typically display times based on the WP time zone setting, so you’d need to consider that in calculating a user’s local time. It’s not unusual for a user’s computer to not accurately reflect their local time zone, but attempting to get the true time zone via IP recognition or similar is even less reliable.

Instead of adjusting times on the fly via JS, I’d include a time zone setting in the user’s profile. It’s default value could come from their computer, but I’d want to let users override that in their profile if they wanted to. I’d then adjust the times server side as they are output. Client side or server side doesn’t really matter, as long as it gets done and is only done once. It’s of course silly to apply a time offset twice, but it has happened accidentally many times.

Thanks very much for the advice, its great to connect with experienced developers………and yes it seems like there is no easy formal solution, i’m from the uk so it’s simple and straightforward if the plugin was being used in the uk, it would use greenwich mean time, this would then make the date of delivery selected and time slots accurate(end user/customer selected), but what happens if this plugin is used outside the uk? would i create an option in settings for the admin to select the time according to where they are based? so then i’m presuming that the end user/customer will then place an order relevant to this set time? im sure im missing something here somewhere…. grabbing the date from a computer like you say has pitfalls….. thanks again, maybe i will need to research it more then design a better solution……..

The time of inserting post data is saved both in local and GMT time. The local time is based upon the timezone field in general settings. The end user’s timezone does not normally factor into what is saved or displayed. In most cases the exact time of a post probably doesn’t matter much, but of course there are scenarios where it is important. WP is not really setup to deal with end user timezones. You figured as much, which is why you’re here ??

TBH, I’ve not had a project where end user timezone was an important factor. Personally, I think timezones are silly and we’d be better off all globally being on UTC. Time is just an arbitrary label anyway. I’m well away from GMT zone, so such a scheme would materially affect me. There’s not going to be an ideal, infallible solution. What I would do if local end user time is important, is include a timezone field in their profile. It would in initially be auto-populated based on their computer’s timezone, but they could override it if need be.

All output to the end user would have times adjusted by this setting. Be sure to include an indication of what timezone is being displayed. If you’re saving timestamps beyond what WP does for posts, you’d want to save similar data, saving as both the WP site’s time and GMT (because the site’s setting is subject to change). Don’t ever save end user timestamps, so that applying end user offset can be consistently done one time only on output. Saving end user timestamps is how offsets end up being applied twice.

It gets even more complicated if you need to reflect daylight/summer times. They are not uniformly applied and switch on varying dates. Rules regarding switches are subject to change. Keeping accurate data on this would be difficult. WP has some way of managing this. I’ve not investigated that part of WP. It’s something you’d want to look into.

thanks again for such a thorough exploration of this issue, yes i think it may be important due to store dispatch cut-off times for next day delivery as it will form part of the new plugin, but you have given me some good tips and ideas how to tack this…

thanks again….

simon