# Upgrading to internal DateTime

- Thread: https://externals.io/message/42111
- Original archive: https://news-web.php.net/php.internals/42111
- Started by Lester Caine on 2008-12-05T06:23:55+00:00
- Messages: 11
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #42111 — Lester Caine — 2008-12-05T06:23:55+00:00

URL: https://externals.io/message/42111#42111

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

---

## #42112 — Derick Rethans — 2008-12-05T09:22:16+00:00

URL: https://externals.io/message/42111#42112 · In reply to: #42111

> 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

---

## #42113 — Karsten Dambekalns — 2008-12-05T10:16:00+00:00

URL: https://externals.io/message/42111#42113 · In reply to: #42112

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

---

## #42114 — Robin Burchell — 2008-12-05T10:47:22+00:00

URL: https://externals.io/message/42111#42114 · In reply to: #42113

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:
> > […]
>
> And how does a unix timestamp preserve timezone information? Or am I
> completely off track?
>
> Regards,
> Karsten

---

## #42115 — Jared Williams — 2008-12-05T12:07:31+00:00

URL: https://externals.io/message/42111#42115 · In reply to: #42111

> -----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 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

---

## #42116 — Jochem Maas — 2008-12-05T15:55:09+00:00

URL: https://externals.io/message/42111#42116 · In reply to: #42112

hi Derick,

Derick Rethans schreef:
> 
> 

...

> > […]
> 
> `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

---

## #42117 — Derick Rethans — 2008-12-05T16:03:44+00:00

URL: https://externals.io/message/42111#42117 · In reply to: #42116

> 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

---

## #42118 — Lester Caine — 2008-12-05T19:03:43+00:00

URL: https://externals.io/message/42111#42118 · In reply to: #42112

Derick Rethans wrote:
> 
> 
> > […]
> 
> 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

---

## #42120 — Lester Caine — 2008-12-06T05:09:07+00:00

URL: https://externals.io/message/42111#42120 · In reply to: #42112

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.

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

---

## #42205 — Jonathan Bond-Caron — 2008-12-09T16:26:01+00:00

URL: https://externals.io/message/42111#42205 · In reply to: #42120

> Derick Rethans wrote:
> > […]
> to
> > […]
> 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 :)

---

## #42212 — pstradomski@gmail.com — 2008-12-10T10:27:18+00:00

URL: https://externals.io/message/42111#42212 · In reply to: #42205

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