Re: [PHP-DEV] Upgrading to internal DateTime
W liście Jonathan Bond-Caron z dnia wtorek 09 grudnia 2008: Unix timestamps are simpler since you know they are always in UTC. Just thought I'd raise that there's nothing wrong with storing all dates as ISO in a given timezone. It takes a little more work but if your consistent, it can managed. If I'm wrong, please let me know :) It's not really feasible to store dates in specific timezone, as most national/local timezones support DST - and that is a pain to support, as eg. sorting breaks when some timestamps get repeated. That's why it's usually better to store datetimes as either UTC datetime or plain unix timestamp. I usually go with the former - using database datetime type. -- Paweł Stradomski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Upgrading to internal DateTime
On Sat Dec 6 12:09 AM, Lester Caine wrote:
Derick Rethans wrote:
( Slipping a date through DateTime and returning it DATE_W3C seems
to
be adding the correct daylight saving details so far and allowing
ADOdb date to work )
This is not the correct thing to do, as you will lose timezone
information. The W3C format only stores UTC offsets (in the form of
+00:00). However, that same UTC offset can be used in different
+areas
with different DST changes. Best thing is to store in Unix
timestamps.
Timezones are a pain :)
OK - I think I understand what is 'missing' now!
The only thing ever stored in the database *IS* Unix timestamps. Doing
anything other than that is unmanageable, yet some frameworks use
'server based' times in their systems, simply because they do not
bother with daylight saving and only 'serve' one timezone!
Not sure I understood this, especially unmanageable. The important part is
to be consistent.
Unix timestamps are useful because they in UTC.
But there is nothing wrong with storing only ISO dates in a database.
Consider these examples:
// Datetime parsed as GMT
date_default_timezone_set('GMT');
$d = new Datetime('2008-06-05 00:00:00');
echo $d-format('U e c'); // 1212624000 'GMT'
// Timestamp parsed as GMT
date_default_timezone_set('America/Montreal');
$d = new Datetime('@1212624000');
echo $d-format('U e c'); // 1212624000 'America/Montreal' --
shouldn't this be UTC?
// Datetime parsed as GMT
date_default_timezone_set('America/Montreal');
$d = new Datetime('2008-06-05 00:00:00', new DatetimeZone('GMT'));
echo $d-format('U e c'); // 1212624000 'UTC' -- not GMT?
// Datetime parsed as 'America/Montreal'
$d = new Datetime('2008-06-05 00:00:00', new
DatetimeZone('America/Montreal'));
echo $d-format('U e c'); // 1212638400 'America/Montreal'
** can any php dev answer the -- questions?
Personally, I prefer storing all dates in a database in a given timezone
(i.e. 'America/Montreal')
It's convenient and easy to read. The big drawback is it needs to clearly
documented that all dates in the database are in this timezone and must be
converted when a) parsing user datetime b) displaying user datetime
i.e.
// From user input to database
$dbDate = new Custom_Datetime($_POST['userDate'], new
DatetimeZone($_POST['userTz']));
$dbDate-setTimeZone('America/Montreal'); // for storing to database
// From database to user
$userDate = new Custom_Datetime($dbDate, new
DatetimeZone('America/Montreal'));
$userDate-setTimeZone($userTz); // to display date in user's timezone
Unix timestamps are simpler since you know they are always in UTC.
Just thought I'd raise that there's nothing wrong with storing all dates as
ISO in a given timezone. It takes a little more work but if your consistent,
it can managed.
If I'm wrong, please let me know :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrading to internal DateTime
On Fri, 5 Dec 2008, Lester Caine wrote: First question. Why are there two different formats for dates with date creation using one format and everything else using strftime formatting? Don't understand what you mean by this. ( Slipping a date through DateTime and returning it DATE_W3C seems to be adding the correct daylight saving details so far and allowing ADOdb date to work ) This is not the correct thing to do, as you will lose timezone information. The W3C format only stores UTC offsets (in the form of +00:00). However, that same UTC offset can be used in different areas with different DST changes. Best thing is to store in Unix timestamps. Second question. What is the current situation on translating dates? I've tried several ways of using setlocale, but at present I've not been able to get anything other than English out of the code. setlocale() is the only real solution right now. What most likely is your problem is that you don't have the locales for the other languages installed. Third question In order to get things working I've ended up with date_default_timezone_set() and haven't needed to use DateTimeZone at all ( other than to get a list for the user to select from ). Internally we are working UTC normalized, and then displaying with the user offset if they select 'local'. IS the correct thing to be setting the default for each user? I suspect yes since previous code has always had to fight the server time setting changing things. Yes, I would do so as well. Especially because all date/time functions use this timezone. DateTime objects however can have information embedded to override this default timezone though. DateTimeZone is only really useful to get information from timezones, to do DST calculations etc. regards, Derick -- HEAD before 5_3!: http://tinyurl.com/6d2esb http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrading to internal DateTime
Hi Derick. Derick Rethans wrote: This is not the correct thing to do, as you will lose timezone information. The W3C format only stores UTC offsets (in the form of +00:00). However, that same UTC offset can be used in different areas with different DST changes. Best thing is to store in Unix timestamps. And how does a unix timestamp preserve timezone information? Or am I completely off track? Regards, Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrading to internal DateTime
A unix timestamp is in UTC, offsets are stored and applied seperately. See tzset(3). Unless someone has misconfigured their system, that is. On Fri, Dec 5, 2008 at 10:16 AM, Karsten Dambekalns [EMAIL PROTECTED] wrote: Hi Derick. Derick Rethans wrote: This is not the correct thing to do, as you will lose timezone information. The W3C format only stores UTC offsets (in the form of +00:00). However, that same UTC offset can be used in different areas with different DST changes. Best thing is to store in Unix timestamps. And how does a unix timestamp preserve timezone information? Or am I completely off track? Regards, Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Upgrading to internal DateTime
-Original Message- From: Lester Caine [mailto:[EMAIL PROTECTED] Sent: 05 December 2008 06:24 To: internals@lists.php.net Subject: [PHP-DEV] Upgrading to internal DateTime OK I spent yesterday working trough some of the idiosyncrasies of DateTime and having had a sleep I've finished off this morning. First question. Why are there two different formats for dates with date creation using one format and everything else using strftime formatting? ( Slipping a date through DateTime and returning it DATE_W3C seems to be adding the correct daylight saving details so far and allowing ADOdb date to work ) Second question. What is the current situation on translating dates? I've tried several ways of using setlocale, but at present I've not been able to get anything other than English out of the code. Intl extension has classes/methods for translating dates. http://www.php.net/manual/en/class.intldateformatter.php . Third question In order to get things working I've ended up with date_default_timezone_set() and haven't needed to use DateTimeZone at all ( other than to get a list for the user to select from ). Internally we are working UTC normalized, and then displaying with the user offset if they select 'local'. IS the correct thing to be setting the default for each user? I suspect yes since previous code has always had to fight the server time setting changing things. Jared -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrading to internal DateTime
hi Derick, Derick Rethans schreef: On Fri, 5 Dec 2008, Lester Caine wrote: ... Second question. What is the current situation on translating dates? I've tried several ways of using setlocale, but at present I've not been able to get anything other than English out of the code. setlocale() is the only real solution right now. What most likely is your problem is that you don't have the locales for the other languages installed. ... leaving aside timezone issues (they make my head hurt, kudos to you for having written that stuff!). according to my testing DateTime ignores the current locale completely ... there seems to be no way of cleanly extracting a locale formatted datetime string from a DateTime object ... there is not even a way to retrieve a unix timestamp from said object in order to pass it to strftime() or to an instance of IntlDateFormatter (which doesn't seem to accept a DateTime object as argument to the format() method. so the only way I can see of doing it is as follows: ?php setlocale(LC_TIME, nl_NL); $d = new DateTime(); echo strftime(%A, %d %B %Y, (int)$d-format(U)), \n; echo $d-format(D, F Y), \n; ? which gives me the following on my local machine: vrijdag, 05 december 2008 Fri, December 2008 having to use ?php (int)$d-format(U) ? seems wrong, having something like ?php $d-getTimeStamp() ? would seem better. Am I missing something? or is there actually a limitation in DateTime that should/will be addressed at some time in the future? personally I just looking to understand ... here's hoping you may be able to shed some light on the matter. rgds, Jochem -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrading to internal DateTime
On Fri, 5 Dec 2008, Jochem Maas wrote: vrijdag, 05 december 2008 Fri, December 2008 having to use ?php (int)$d-format(U) ? seems wrong, having something like ?php $d-getTimeStamp() ? would seem better. Am I missing something? or is there actually a limitation in DateTime that should/will be addressed at some time in the future? personally I just looking to understand ... here's hoping you may be able to shed some light on the matter. get/setTimestamp have been added in PHP 5.3. regards, Derick -- HEAD before 5_3!: http://tinyurl.com/6d2esb http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrading to internal DateTime
Derick Rethans wrote: On Fri, 5 Dec 2008, Lester Caine wrote: First question. Why are there two different formats for dates with date creation using one format and everything else using strftime formatting? Don't understand what you mean by this. http://uk.php.net/manual/en/function.strftime.php uses %* formatting while the newer 'format' uses single characters http://uk.php.net/manual/en/function.date.php I'm just used to strftime style and all of the ADOdb formatting is based on that ... I never realised there was two formats, so re-engineering to use format is not really practical. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrading to internal DateTime
Derick Rethans wrote: ( Slipping a date through DateTime and returning it DATE_W3C seems to be adding the correct daylight saving details so far and allowing ADOdb date to work ) This is not the correct thing to do, as you will lose timezone information. The W3C format only stores UTC offsets (in the form of +00:00). However, that same UTC offset can be used in different areas with different DST changes. Best thing is to store in Unix timestamps. OK - I think I understand what is 'missing' now! The only thing ever stored in the database *IS* Unix timestamps. Doing anything other than that is unmanageable, yet some frameworks use 'server based' times in their systems, simply because they do not bother with daylight saving and only 'serve' one timezone! The second you have to manage 'real' time across timezones then daylight saving becomes essential, BUT only on the display side! Since the browser only provides a time offset, this is useless and to be honest should simply be ignored ( until it is upgraded to provide the correct information ;) ). So we need a 'display' function that takes a simple numeric epoch, and a separate timezone id into which the epoch is to be 'converted'. My W3C mapping works simply because ADOdb then converts that to it's own simple offset abbreviation - in my case GMT or BST. As long as DateTime passes the full 64 bit number the date range from 100AD is also preserved ( and further back if 2 digit years are disabled ). If I want to display the 'real' timezone with this 'time' then I just add it in place of ADOdb's 'timezone'. I am tempted to simply adjust the ADOdb class to take a timezone in place of the simple GMT switch it currently uses. The return path is just the reverse and simply needs to take the client display offset off prior to storage of the UTC epoch. SO we use DateTimeZone to get an offset value for the clients timezone and simply add or subtract this from a timezone agnostic display on the client end when entering new times. ( I've posted this simply as an aid - it may help someone ) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
