1

I am bulding a component for joomla which has announcements for others. And that announcements have creation date and date for its events. My clients can be in different countries. One can be in two countries in two different moment. So his timezone should be dynamic I think. which way is better to set the creation date and event date for this type of problem.

Elin
  • 6,507
  • 3
  • 25
  • 47
freezer
  • 531
  • 1
  • 11
  • 28

3 Answers3

2

Joomla handles that automatically as along as you don't store as anything but UTC.

Elin
  • 6,507
  • 3
  • 25
  • 47
  • When I use JFactory::getDate()->toMySQL(); it displays the date in my timezone but it stores the date in UTC I am in Istanbul if my time is 05:00 it displays it rigth but it stores it as 03:00 – freezer Feb 05 '13 at 13:56
  • Exactly and that's why it will display right to users where they are. It would display to me in NYC time. – Elin Feb 05 '13 at 14:02
  • Ohh I figured it out now. So, do I need to store it as unix time stamp or not. Additionally I am using the getDate($date, JFActory::getConfig()->getValue('config.offset')) but it takes the time zone wihch is set in configuraiton file. but how can I set it for indivdual user I am assuming that those users never set its timezones :D – freezer Feb 05 '13 at 14:05
  • datetime is what Joomla generally stores and expects. – Elin Feb 05 '13 at 14:13
0

I would always save datetime in GMT and display it on PHP side as required, based on the timezone you can get from that user's browser header, IP address or some profile setting.

Even if the client is in 2 different timezones, you should be able to track on which browser (from which timezone) they're viewing the page this way.

Zathrus Writer
  • 4,311
  • 5
  • 27
  • 50
  • I have no idea for about how to obtain the timezone of the client porperly. – freezer Feb 05 '13 at 13:58
  • just as I said - from their IP address would be an ideal solution, but requires a call to some [GeoIP API](http://ipinfodb.com/) or a use of [geoip PHP functions](http://www.php.net/manual/en/function.geoip-country-code-by-name.php) – Zathrus Writer Feb 05 '13 at 14:04
  • also check out [this link](http://stackoverflow.com/questions/5203382/how-to-automatically-detect-users-timezone) and [this link](http://stackoverflow.com/questions/409999/getting-the-location-from-an-ip-address) – Zathrus Writer Feb 05 '13 at 14:06
0

You should ALWAYS store data in UTC (GMT) time, ideally in the form of a Unix timestamp. This is a standard that is not subject to any type of Daylight Savings Time changes and is perfect for saving a constant point in time.

Then, when displaying the date and time to an individual user, you can convert that timestamp into their local date and time.

Anton
  • 3,998
  • 25
  • 40
  • let say, A vehicle will be move from one country to other. Its leaving time should be indicated. So I will stroe in as unix timestamp to be reliable. But when a user looks to that vehicles datas it will see that time. Which timezone is proper for it the time zone of the country wihch is the place where the car will start its moving or the timezone of client ? – freezer Feb 05 '13 at 13:55
  • And what should be the database table column properties. What is the difference of UTC and GMT – freezer Feb 05 '13 at 13:58
  • 1
    If he issue is what is rendered from the UTC time then you need to deal with that. IF you only want it to show in the time zone of a specific city then you need to do that on the rendering side by giving it a specific format. Look at how the core handles data via JText. – Elin Feb 05 '13 at 14:06
  • Regarding your db column question, in MySQL there's a TIMESTAMP column data type. Something similar is available in all major database systems. – Anton Feb 05 '13 at 14:35
  • joomla uses DATETIME. Is there any difference between DATEYIME and TIMESTAMP. Still I couldnt get the timezone to use in php code :S – freezer Feb 05 '13 at 15:25
  • TIMESTAMP is usually updated every time a table is updated, unless you set it up in a way that that doesn't happen. DATETIME is like that, except it doesn't update in this way. Now that I think about it, DATETIME is a better practice anyway. – Anton Feb 05 '13 at 15:32