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.
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.
--
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
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 withdate_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
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
A unix timestamp is in UTC, offsets are stored and applied seperately.
See tzset(3).
Unless someone has misconfigured their system, that is.
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
hi Derick,
Derick Rethans schreef:
...
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
vrijdag, 05 december 2008
Fri, December 2008having 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
Derick Rethans 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
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
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 :)
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
-----Original Message-----
From: Lester Caine [mailto:lester@lsces.co.uk]
Sent: 05 December 2008 06:24
To: internals@lists.php.net
Subject: [PHP-DEV] Upgrading to internal DateTimeOK 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