RFC for Adding __toString to DateTime

13 years ago by Will Fitch — view source — reply

unread

I would like to officially introduce an RFC with a patch to implement
__toString to DateTime. This is a commonly requested feature that goes
unanswered mostly because of the inability to agree on a default pattern.

In short, the patch uses the ISO-8601 format as the default pattern. The
pattern may be changed via setDefaultPattern and date_default_pattern_set,
as explained in the RFC.

The link to the RFC and patch are here:
https://wiki.php.net/rfc/datetime_tostring.

While I know this isn't as interesting as many of the current proposals
going on, I'm hoping you can give this RFC a look.

Will

13 years ago by Andrew Faulds — view source — reply

unread

I would like to officially introduce an RFC with a patch to implement
__toString to DateTime. This is a commonly requested feature that goes
unanswered mostly because of the inability to agree on a default pattern.

In short, the patch uses the ISO-8601 format as the default pattern. The
pattern may be changed via setDefaultPattern and date_default_pattern_set,
as explained in the RFC.

The link to the RFC and patch are here:
https://wiki.php.net/rfc/datetime_tostring.

While I know this isn't as interesting as many of the current proposals
going on, I'm hoping you can give this RFC a look.

Will

Oh, thank you Will! I saw the bug report suggesting it myself and was
thinking of implementing it. I'm glad to see you thought the same way I
did, and used the ISO-8601 format as the default.

+1 from me.

--
Andrew Faulds
http://ajf.me/

13 years ago by Pierre Joye — view source — reply

unread

hi Will,

I would like to officially introduce an RFC with a patch to implement
__toString to DateTime. This is a commonly requested feature that goes
unanswered mostly because of the inability to agree on a default pattern.

In short, the patch uses the ISO-8601 format as the default pattern. The
pattern may be changed via setDefaultPattern and date_default_pattern_set,
as explained in the RFC.

The link to the RFC and patch are here:
https://wiki.php.net/rfc/datetime_tostring.

While I know this isn't as interesting as many of the current proposals
going on, I'm hoping you can give this RFC a look.

It would be better to name the format method setDefaultFormat instead
of setDefaultPattern, to be consistent with the rest of the API.

(not saying I like the idea or not, only a 1st comment :)

Cheers,

Pierre

@pierrejoye

13 years ago by Will Fitch — view source — reply

unread

hi Will,

I would like to officially introduce an RFC with a patch to implement
__toString to DateTime. This is a commonly requested feature that goes
unanswered mostly because of the inability to agree on a default pattern.

In short, the patch uses the ISO-8601 format as the default pattern. The
pattern may be changed via setDefaultPattern and
date_default_pattern_set,
as explained in the RFC.

The link to the RFC and patch are here:
https://wiki.php.net/rfc/datetime_tostring.

While I know this isn't as interesting as many of the current proposals
going on, I'm hoping you can give this RFC a look.

It would be better to name the format method setDefaultFormat instead
of setDefaultPattern, to be consistent with the rest of the API.

This makes sense. I'll update.

(not saying I like the idea or not, only a 1st comment :)

Cheers,

Pierre

@pierrejoye

13 years ago by Sherif Ramadan — view source — reply

unread

I would like to officially introduce an RFC with a patch to implement
__toString to DateTime. This is a commonly requested feature that goes
unanswered mostly because of the inability to agree on a default pattern.

In short, the patch uses the ISO-8601 format as the default pattern. The
pattern may be changed via setDefaultPattern and date_default_pattern_set,
as explained in the RFC.

The link to the RFC and patch are here:
https://wiki.php.net/rfc/datetime_tostring.

While I know this isn't as interesting as many of the current proposals
going on, I'm hoping you can give this RFC a look.

Will

I think you should consider making the get/setDefaultPattern() methods
into a public string called $format and just put it in the constructor
with an initial value of DateTime::ISO8601

It'd be a much simple implementation and doesn't require introducing
new functions. DateTime can either throw an exception if the format is
invalid or silently fall back to the DateTime::ISO8601

No need to complicate this.

13 years ago by Derick Rethans — view source — reply

unread

I would like to officially introduce an RFC with a patch to implement
__toString to DateTime. This is a commonly requested feature that goes
unanswered mostly because of the inability to agree on a default pattern.

In short, the patch uses the ISO-8601 format as the default pattern. The
pattern may be changed via setDefaultPattern and date_default_pattern_set,
as explained in the RFC.

The default should most definitely not be ISO-8601 - as it's a lossy
format.

The link to the RFC and patch are here:
https://wiki.php.net/rfc/datetime_tostring.

Methods Added

void DateTime::setDefaultPattern(string $pattern)
string DateTime::getDefaultPattern(void)

This should be descriptive. You are only dealing with __toString here.
Hence the method names should reflect that:

void DateTime::setToStringFormat(string $pattern)
string DateTime::getToStringFormat(void)

However, I still don't believe this belongs in the class at all. It is
rather trivial to do this in userland:

class MyDateTime extends DateTime {
static $format = "... some format...";
function __toString() { return $this->format(DateTime::$format); }
}

There, 4 lines. And no quaralling about formats or naming.

<?php
$date = new DateTime('2012-09-01 02:43:00');
print_r($date);

Should not output just:

DateTime Object
(
[date] => 2012-09-01 02:43:00
[timezone_type] => 3
[timezone] => America/Chicago
)

But instead should always have the tostring pattern in there.

Also, have you checked whether it shows up when you run serialize on it?

cheers,
Derick

13 years ago by Will Fitch — view source — reply

unread

I would like to officially introduce an RFC with a patch to implement
__toString to DateTime. This is a commonly requested feature that goes
unanswered mostly because of the inability to agree on a default pattern.

In short, the patch uses the ISO-8601 format as the default pattern. The
pattern may be changed via setDefaultPattern and
date_default_pattern_set,
as explained in the RFC.

The default should most definitely not be ISO-8601 - as it's a lossy
format.

In terms of lossy transmission/storage, what concerns in regards to the
pattern are you referring to? ISO-8601 is only output if there is no
pre-set pattern provided. So in essance,

The link to the RFC and patch are here:
https://wiki.php.net/rfc/datetime_tostring.

Methods Added

void DateTime::setDefaultPattern(string $pattern)
string DateTime::getDefaultPattern(void)

This should be descriptive. You are only dealing with __toString here.
Hence the method names should reflect that:

void DateTime::setToStringFormat(string $pattern)
string DateTime::getToStringFormat(void)

However, I still don't believe this belongs in the class at all. It is
rather trivial to do this in userland:

class MyDateTime extends DateTime {
static $format = "... some format...";
function __toString() { return $this->format(DateTime::$format); }
}

There, 4 lines. And no quaralling about formats or naming.

I'm definitely not sold on any naming convention or format, and I don't see
any quarrelling going on. The purpose of the RFC is to come up with a
solution and discuss implementation. I don't expect any quarrels for
something this simple.

I would like this discussed. This is a feature often brought up and
requested. I understand that it may be difficult to come to a solution,
but let's try.

<?php
$date = new DateTime('2012-09-01 02:43:00');
print_r($date);

Should not output just:

DateTime Object
(
[date] => 2012-09-01 02:43:00
[timezone_type] => 3
[timezone] => America/Chicago
)

But instead should always have the tostring pattern in there.

I agree and will update.

Also, have you checked whether it shows up when you run serialize on it?

The patch I originally wrote did implement wakeup and set state.
Unfortunately, an accidental git checkout -- in the wrong path gave me the
distinct pleasure of rewriting this.

cheers,
Derick

13 years ago by Derick Rethans — view source — reply

unread

I would like to officially introduce an RFC with a patch to implement
__toString to DateTime. This is a commonly requested feature that goes
unanswered mostly because of the inability to agree on a default pattern.

In short, the patch uses the ISO-8601 format as the default pattern. The
pattern may be changed via setDefaultPattern and
date_default_pattern_set,
as explained in the RFC.

The default should most definitely not be ISO-8601 - as it's a lossy
format.

In terms of lossy transmission/storage, what concerns in regards to the
pattern are you referring to?

$ php -r 'echo date_create()->format( DateTime::ISO8601 );'
2012-09-02T12:26:17+0100
^^^^^

is the lossless bit. It tells you nothing about the timezone. This is
why var_dump(date_create()) has:

public $timezone => string(13) "Europe/London"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ISO-8601 is only output if there is no pre-set pattern provided. So
in essance,

in essance?

The link to the RFC and patch are here:
https://wiki.php.net/rfc/datetime_tostring.

Methods Added

void DateTime::setDefaultPattern(string $pattern)
string DateTime::getDefaultPattern(void)

This should be descriptive. You are only dealing with __toString here.
Hence the method names should reflect that:

void DateTime::setToStringFormat(string $pattern)
string DateTime::getToStringFormat(void)

However, I still don't believe this belongs in the class at all. It is
rather trivial to do this in userland:

class MyDateTime extends DateTime {
static $format = "... some format...";
function __toString() { return $this->format(DateTime::$format); }
}

There, 4 lines. And no quaralling about formats or naming.

I'm definitely not sold on any naming convention or format, and I don't see
any quarrelling going on. The purpose of the RFC is to come up with a
solution and discuss implementation. I don't expect any quarrels for
something this simple.

Right, it's so simple that it can be done in userland in 4 lines of
code. I don't want to add this.

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

13 years ago by Stas Malyshev — view source — reply

unread

Hi!

I would like to officially introduce an RFC with a patch to implement
__toString to DateTime. This is a commonly requested feature that goes
unanswered mostly because of the inability to agree on a default pattern.

This must indicate there's actually no default pattern that is "default"
for everyone. Which suggests maybe we shouldn't have default string
conversion there?
After all, nothing prevents one from having:

class MyDateTime extends DateTime {
public function __toString() {
return $this->format(/* whatever my favorite format is */);
}
}

I'm not sure introducing special state to DateTime for it is the best
way to handle it. Also, most applications would have common date format

which means since the state is per DateTime object, they'd have to
watch that every object produced would have this property set. I think
it'd be easier to just use DateTime->format() - this way you know what
is produced and it is clear for whoever is reading the code too.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

13 years ago by Will Fitch — view source — reply

unread

On Sat, Sep 1, 2012 at 9:54 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:

Hi!

I would like to officially introduce an RFC with a patch to implement
__toString to DateTime. This is a commonly requested feature that goes
unanswered mostly because of the inability to agree on a default pattern.

This must indicate there's actually no default pattern that is "default"
for everyone. Which suggests maybe we shouldn't have default string
conversion there?
After all, nothing prevents one from having:

class MyDateTime extends DateTime {
public function __toString() {
return $this->format(/* whatever my favorite format is */);
}
}

I'm not sure introducing special state to DateTime for it is the best
way to handle it. Also, most applications would have common date format

which means since the state is per DateTime object, they'd have to
watch that every object produced would have this property set. I think
it'd be easier to just use DateTime->format() - this way you know what
is produced and it is clear for whoever is reading the code too.

Hi, Stas. This has been on my mind as well. I've considered that maybe an
INI wide setting would be beneficial here. In fact, there are many places
within applications I've worked on where the format for many DateTime
objects are the same. What are your thoughts on that?

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

13 years ago by Lester Caine — view source — reply

unread

Will Fitch wrote:

I'm not sure introducing special state to DateTime for it is the best

way to handle it. Also, most applications would have common date format

which means since the state is per DateTime object, they'd have to
watch that every object produced would have this property set. I think
it'd be easier to just use DateTime->format() - this way you know what
is produced and it is clear for whoever is reading the code too.

Hi, Stas. This has been on my mind as well. I've considered that maybe an
INI wide setting would be beneficial here. In fact, there are many places
within applications I've worked on where the format for many DateTime
objects are the same. What are your thoughts on that?

Will - while I can understand the desire to bring datetime in line with other
objects, the amount of trouble some of us have with trying to identify between
American and English dates and identifying the clients correct time zone does
make this something of a minefield. As Derick has said, ISO-8601 is not the best
choice because of the timezone problem, and until browsers actually provide a
correct timezone setting this is often wrong for half of the year. 'HTTP
Cookies' does at least include timezone, but I'd not want to use that as a
default because it's too verbose. I prefer internally to work with UTC time only
and fix everything to that, and then display in the CLIENT's identified format,
so a server default setting is a little pointless ... and in my book should be
simple UTC all the time :)

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

13 years ago by Stas Malyshev — view source — reply

unread

Hi!

Hi, Stas. This has been on my mind as well. I've considered that maybe
an INI wide setting would be beneficial here. In fact, there are many
places within applications I've worked on where the format for many
DateTime objects are the same. What are your thoughts on that?

I think yet another ini setting is not a good solution, ini settings are
hard to control and they are not meant to deal with application-specific
things, since they're global.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

13 years ago by Derick Rethans — view source — reply

unread

On Sat, Sep 1, 2012 at 9:54 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:

I would like to officially introduce an RFC with a patch to
implement __toString to DateTime. This is a commonly requested
feature that goes unanswered mostly because of the inability to
agree on a default pattern.

This must indicate there's actually no default pattern that is
"default" for everyone. Which suggests maybe we shouldn't have
default string conversion there? After all, nothing prevents one
from having:

class MyDateTime extends DateTime {
public function __toString() {
return $this->format(/* whatever my favorite format is */);
}
}

I'm not sure introducing special state to DateTime for it is the
best way to handle it. Also, most applications would have common
date format - which means since the state is per DateTime object,
they'd have to watch that every object produced would have this
property set. I think it'd be easier to just use DateTime->format()

this way you know what is produced and it is clear for whoever is
reading the code too.

This has been on my mind as well. I've considered that maybe an INI
wide setting would be beneficial here.

We should absolutely NOT add ini settings for this. They make things
unportable.

In fact, there are many places
within applications I've worked on where the format for many DateTime
objects are the same. What are your thoughts on that?

Inherit it in userland!

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

13 years ago by Pierre Joye — view source — reply

unread

We should absolutely NOT add ini settings for this. They make things
unportable.

Agreed.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Andrew Faulds — view source — reply

unread

We should absolutely NOT add ini settings for this. They make things
unportable.
Agreed.
Add my name to the list. PHP's ini settings are one of its bad points,
IMO. We don't need any more of them.

--
Andrew Faulds
http://ajf.me/

13 years ago by Benjamin Eberlei — view source — reply

unread

I think allowing to change teh default format would be horrible. If
libraries (such as Doctrine would) use this internally, they are at the
will of users not to fiddle with this setting. Not to speak about libraries
that contradict each other.

If there was a format, it would have to be constant imho.

We should absolutely NOT add ini settings for this. They make things

unportable.

Agreed.

Add my name to the list. PHP's ini settings are one of its bad points,
IMO. We don't need any more of them.

--
Andrew Faulds
http://ajf.me/

13 years ago by Andrew Faulds — view source — reply

unread

I think allowing to change teh default format would be horrible. If
libraries (such as Doctrine would) use this internally, they are at
the will of users not to fiddle with this setting. Not to speak about
libraries that contradict each other.

If there was a format, it would have to be constant imho.
Then ISO8601, please. It's a single, unambiguous Date and Time format.

--
Andrew Faulds
http://ajf.me/

13 years ago by Lester Caine — view source — reply

unread

Andrew Faulds wrote:

I think allowing to change teh default format would be horrible. If libraries
(such as Doctrine would) use this internally, they are at the will of users
not to fiddle with this setting. Not to speak about libraries that contradict
each other.

If there was a format, it would have to be constant imho.
Then ISO8601, please. It's a single, unambiguous Date and Time format.
WRONG !!!

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

13 years ago by Derick Rethans — view source — reply

unread

I think allowing to change teh default format would be horrible. If
libraries (such as Doctrine would) use this internally, they are at the will
of users not to fiddle with this setting. Not to speak about libraries that
contradict each other.

If there was a format, it would have to be constant imho.

Then ISO8601, please. It's a single, unambiguous Date and Time format.

No it's not unambigious:

$ php -r 'date_default_timezone_set("Europe/London"); echo date_create()->format(DateTime::ISO8601), "\n";'
2012-09-02T18:17:36+0100

$ php -r 'date_default_timezone_set("Africa/Niamey"); echo date_create()->format(DateTime::ISO8601), "\n";'
2012-09-02T18:19:05+0100

vs:

$ php -r 'date_default_timezone_set("Africa/Niamey"); echo date_create("2012-12-31")->format(DateTime::ISO8601), "\n";'
2012-12-31T00:00:00+0100
^^^^^

$ php -r 'date_default_timezone_set("Europe/London"); echo date_create("2012-12-31")->format(DateTime::ISO8601), "\n";'
2012-12-31T00:00:00+0000
^^^^^

cheers,
Derick

13 years ago by Lester Caine — view source — reply

unread

Derick Rethans wrote:

Then ISO8601, please. It's a single, unambiguous Date and Time format.
No it's not unambigious:

Derick - is this effect just due to daylight saving differences, or IS it a bit
more complex than that?

Personally I don't want any timezone/offset displayed as I expect it to be a UTC
time by default on the server, rather than any offset time, which is why I'm
with you that it should only be changed via user space applications.

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

13 years ago by William Betts — view source — reply

unread

Personally I don't want any timezone/offset displayed as I expect it to be a
UTC time by default on the server, rather than any offset time, which is why
I'm with you that it should only be changed via user space applications.

--
Lester Caine - G8HFL

Personally, if I have my way I will always use UTC server side. I
think most people
would expect / want UTC time by default on the server as well. It's
been considered
best practice for years.

13 years ago by Derick Rethans — view source — reply

unread

Derick Rethans wrote:

Then ISO8601, please. It's a single, unambiguous Date and Time format.
No it's not unambigious:

Derick - is this effect just due to daylight saving differences, or IS it a
bit more complex than that?

This one illustrated DST issues - but it's very likely going to be more
complex that that...

Personally I don't want any timezone/offset displayed as I expect it
to be a UTC time by default on the server, rather than any offset
time, which is why I'm with you that it should only be changed via
user space applications.

Yes, and other people expect their timezone in it, and other just local
time and others... my point here being that you can't pick a format that
works for everybody...

cheers,
Derick

13 years ago by Andrew Faulds — view source — reply

unread

No it's not unambigious:

$ php -r 'date_default_timezone_set("Europe/London"); echo date_create()->format(DateTime::ISO8601), "\n";'
2012-09-02T18:17:36+0100

$ php -r 'date_default_timezone_set("Africa/Niamey"); echo date_create()->format(DateTime::ISO8601), "\n";'
2012-09-02T18:19:05+0100

vs:

$ php -r 'date_default_timezone_set("Africa/Niamey"); echo date_create("2012-12-31")->format(DateTime::ISO8601), "\n";'
2012-12-31T00:00:00+0100
^^^^^

$ php -r 'date_default_timezone_set("Europe/London"); echo date_create("2012-12-31")->format(DateTime::ISO8601), "\n";'
2012-12-31T00:00:00+0000
^^^^^
I'm a little confused as to what is going on here, but ISO8601 has a UTC
format, YYYY-MM-DDTHH:MM:SSZ.
cheers,
Derick

--
Andrew Faulds
http://ajf.me/

13 years ago by Derick Rethans — view source — reply

unread

No it's not unambigious:

$ php -r 'date_default_timezone_set("Europe/London"); echo
date_create()->format(DateTime::ISO8601), "\n";'
2012-09-02T18:17:36+0100

$ php -r 'date_default_timezone_set("Africa/Niamey"); echo
date_create()->format(DateTime::ISO8601), "\n";'
2012-09-02T18:19:05+0100

vs:

$ php -r 'date_default_timezone_set("Africa/Niamey"); echo
date_create("2012-12-31")->format(DateTime::ISO8601), "\n";'
2012-12-31T00:00:00+0100
^^^^^

$ php -r 'date_default_timezone_set("Europe/London"); echo
date_create("2012-12-31")->format(DateTime::ISO8601), "\n";'
2012-12-31T00:00:00+0000
^^^^^
I'm a little confused as to what is going on here, but ISO8601 has a UTC
format, YYYY-MM-DDTHH:MM:SSZ.

Yes, and that format is ambigious like I just illustrated.

cheers,
Derick

13 years ago by Andrew Faulds — view source — reply

unread

Yes, and that format is ambigious like I just illustrated. cheers, Derick

No, you just demonstrated the time offset format is ambiguous, not the
UTC format.

--
Andrew Faulds
http://ajf.me/

13 years ago by Derick Rethans — view source — reply

unread

Yes, and that format is ambigious like I just illustrated. cheers,
Derick

No, you just demonstrated the time offset format is ambiguous, not the
UTC format.

Yes, I am saying that ISO8601 is lossy - and that is something that
shouldn't be the default format.

Cheers,
Derick

13 years ago by Andrew Faulds — view source — reply

unread

Yes, I am saying that ISO8601 is lossy - and that is something that
shouldn't be the default format.

Lossy of what? Local timezone?

ISO 8601 is the single unambiguously ordered (no mm-dd/dd-mm confusion),
international standard, machine-readable (default in ECMAScript, for
instance) date/time format.

I see no reason not to use it. Date/time should be UTC anyway when
debugging.

--
Andrew Faulds
http://ajf.me/

13 years ago by Derick Rethans — view source — reply

unread

Yes, I am saying that ISO8601 is lossy - and that is something that
shouldn't be the default format.

Lossy of what? Local timezone?

ISO 8601 is the single unambiguously ordered (no mm-dd/dd-mm
confusion), international standard, machine-readable (default in
ECMAScript, for instance) date/time format.

I see no reason not to use it. Date/time should be UTC anyway when
debugging.

Yeah, I understand you don't see a reason. That's what scares me. For
debugging I definetely wouldn't want to have my datetimes mangled to
just show UTC. I wouldn't even be able to see the difference between 4pm
London and 5pm Amsterdam time!

cheers,
Derick

13 years ago by Peter Cowburn — view source — reply

unread

Yeah, I understand you don't see a reason. That's what scares me. For
debugging I definetely wouldn't want to have my datetimes mangled to
just show UTC. I wouldn't even be able to see the difference between 4pm
London and 5pm Amsterdam time!

cheers,
Derick

Dear Derick et al.,

If you are going to pick a default __toString() format, please,
please, please, please, please pick one that a) has all of the
information stored in a DateTime object, such that b) I can feed that
string representation back into the constructor and get an identical
DateTime object back. I have yet to see an example in this thread
that includes microseconds, for example. And the suggestions to have
the GMT offset only is, worrying.

The suggestion to have the string always be returned in UTC is also
(perhaps more so) of concern. I'm all for advocating that folks work
with UTC consistently internally in their code, but having the default
string representation use UTC regardless of what the DateTime object
is representing… just, wow.

Overall, I'm a big -1 to this whole idea.

Finally, why should "echo $datetime;" be expected to work at all,
since 95% of the time it's only going to be echo'd plain like that for
debugging purposes as we'll never pick the "right" format to use in
everyone's code. When needing to set the "default" (read:
per-instance) string format with something like setToStringFormat() or
whatever, that becomes more work than just calling format().

Thank you kindly,
Peter

13 years ago by Lester Caine — view source — reply

unread

Peter Cowburn wrote:

Finally, why should "echo $datetime;" be expected to work at all,
since 95% of the time it's only going to be echo'd plain like that for
debugging purposes as we'll never pick the "right" format to use in
everyone's code. When needing to set the "default" (read:
per-instance) string format with something like setToStringFormat() or
whatever, that becomesmore work than just calling format().

Hopefully Will now understands just how problematic his request is, and why it
has not been implemented as yet. I'm with you but for a slightly different
reason. I never run anything but UTC on the server. So I'm only displaying
anything other than UTC when handling a client view of the data. So I would
normally be calling format with the client timezone data.

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

13 years ago by Will Fitch — view source — reply

unread

Peter Cowburn wrote:

Finally, why should "echo $datetime;" be expected to work at all,
since 95% of the time it's only going to be echo'd plain like that for
debugging purposes as we'll never pick the "right" format to use in
everyone's code. When needing to set the "default" (read:
per-instance) string format with something like setToStringFormat() or
whatever, that becomesmore work than just calling format().

Hopefully Will now understands just how problematic his request is, and
why it has not been implemented as yet. I'm with you but for a slightly
different reason. I never run anything but UTC on the server. So I'm only
displaying anything other than UTC when handling a client view of the data.
So I would normally be calling format with the client timezone data.

It is problematic because that is what we choose to make it. Right now, a
catchable fatal error is produced. That is problematic. ISO8601 is not
lossy nor is UTC. It can be taken by any other language and converted based
on the format itself.

We have standards for a reason. I agree that changing that should not be
allowed. I will remove the set/get pattern functions and only print a
standard format. Printing an ISO standard format, which includes the TZ
based on UTC, or even the UTC format itself is a better solution than a
catchable fatal error.

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

13 years ago by Derick Rethans — view source — reply

unread

Peter Cowburn wrote:

Finally, why should "echo $datetime;" be expected to work at all,
since 95% of the time it's only going to be echo'd plain like that for
debugging purposes as we'll never pick the "right" format to use in
everyone's code. When needing to set the "default" (read:
per-instance) string format with something like setToStringFormat() or
whatever, that becomesmore work than just calling format().

Hopefully Will now understands just how problematic his request is, and
why it has not been implemented as yet. I'm with you but for a slightly
different reason. I never run anything but UTC on the server. So I'm only
displaying anything other than UTC when handling a client view of the data.
So I would normally be calling format with the client timezone data.

It is problematic because that is what we choose to make it. Right now, a
catchable fatal error is produced. That is problematic. ISO8601 is not
lossy nor is UTC.

This tells me you haven't researched this subject properly. So let me
demonstrate once more:

$d = date_create( "2012-09-03 09:13:52" );
var_dump( $d );
$s = $d->format( DateTime::ISO8601 );
$d = date_create( $s );
var_dump( $d );

Outputs:

class DateTime#1 (3) {
public $date =>
string(19) "2012-09-03 09:13:52"
public $timezone_type =>
int(3)
public $timezone =>
string(13) "Europe/London"
}

class DateTime#2 (3) {
public $date =>
string(19) "2012-09-03 09:13:52"
public $timezone_type =>
int(1)
public $timezone =>
string(6) "+01:00"
}

And voila, you've just lost the timezone that belongs to the DateTime
object.

We have standards for a reason. I agree that changing that should not
be allowed. I will remove the set/get pattern functions and only print
a standard format. Printing an ISO standard format, which includes the
TZ based on UTC, or even the UTC format itself is a better solution
than a catchable fatal error.

I disagree as it is an Ostrich Method. Instead of fixing your problem
you'll just be hiding it.

Derick

13 years ago by Ryan McCue — view source — reply

unread

As far as I can tell, there's no standard which uses the Olson database
to specify the timezone, so we'd have to create one.

What about ISO8601 with the Olson timezone suffixed?

2012-09-02T18:17:36+0100 (Europe/London)
2012-09-02T18:19:05+0100 (Africa/Niamey)

--
Ryan McCue
<http://ryanmccue.info/

13 years ago by Andrew Faulds — view source — reply

unread

Ryan McCue lists@rotorised.com wrote:

As far as I can tell, there's no standard which uses the Olson database
to specify the timezone, so we'd have to create one.

What about ISO8601 with the Olson timezone suffixed?

2012-09-02T18:17:36+0100 (Europe/London)
2012-09-02T18:19:05+0100 (Africa/Niamey)

Sounds good.

--
Ryan McCue
http://ryanmccue.info/

--

--
Sent from my Android phone with K-9 Mail.
Andrew Faulds
http://ajf.me/

13 years ago by Adam Harvey — view source — reply

unread

Ryan McCue lists@rotorised.com wrote:

What about ISO8601 with the Olson timezone suffixed?

2012-09-02T18:17:36+0100 (Europe/London)
2012-09-02T18:19:05+0100 (Africa/Niamey)

Sounds good.

If we're going to invent arbitrary non-standard formats, why don't we
just tell people to use json_encode($dateTime) and be done with it?

I just don't see how we can choose a sensible default format for
users. Sometimes you want ISO 8601. Sometimes you want whatever your
locale's customary date format is. Sometimes you want US m/d/y dates
for interacting with legacy systems. RFC 2822. RFC 822, natch. And so
on. I don't see why one format should be blessed over others and have
magic behaviour when a DateTime object is cast to a string. IMO, the
fact that users have to provide a format string and call format() is a
good thing: explicit beats implicit, every day of the week.

No matter what format string you use to iterate over said days.

Adam

13 years ago by Peter Lind — view source — reply

unread

Best solution from a random developers perspective:

stick the 4-line solution in the docs and on to the bug report. Then
mark as won't implement

It's a far better solution than choosing a random format for users, as
should be more than evident by now.

Regards
Peter

--
<hype>
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
</hype

13 years ago by Derick Rethans — view source — reply

unread

Ryan McCue lists@rotorised.com wrote:

What about ISO8601 with the Olson timezone suffixed?

2012-09-02T18:17:36+0100 (Europe/London)
2012-09-02T18:19:05+0100 (Africa/Niamey)

Sounds good.

If we're going to invent arbitrary non-standard formats, why don't we
just tell people to use json_encode($dateTime) and be done with it?

That, or just call ->format() on the DateTime object!

I just don't see how we can choose a sensible default format for
users. Sometimes you want ISO 8601. Sometimes you want whatever your
locale's customary date format is. Sometimes you want US m/d/y dates
for interacting with legacy systems. RFC 2822. RFC 822, natch. And so
on. I don't see why one format should be blessed over others and have
magic behaviour when a DateTime object is cast to a string. IMO, the
fact that users have to provide a format string and call format() is a
good thing: explicit beats implicit, every day of the week.

No matter what format string you use to iterate over said days.

+1

cheers,
Derick

13 years ago by Will Fitch — view source — reply

unread

Ryan McCue lists@rotorised.com wrote:

What about ISO8601 with the Olson timezone suffixed?

2012-09-02T18:17:36+0100 (Europe/London)
2012-09-02T18:19:05+0100 (Africa/Niamey)

Sounds good.

If we're going to invent arbitrary non-standard formats, why don't we
just tell people to use json_encode($dateTime) and be done with it?

I just don't see how we can choose a sensible default format for
users. Sometimes you want ISO 8601. Sometimes you want whatever your
locale's customary date format is. Sometimes you want US m/d/y dates
for interacting with legacy systems. RFC 2822. RFC 822, natch. And so
on. I don't see why one format should be blessed over others and have
magic behaviour when a DateTime object is cast to a string. IMO, the
fact that users have to provide a format string and call format() is a
good thing: explicit beats implicit, every day of the week.

You absolutely made the case for using DateTime::format() - which is not
the proposal here. This is for a string representation of the object via
toString.

No matter what format string you use to iterate over said days.

Adam

13 years ago by Adam Harvey — view source — reply

unread

I just don't see how we can choose a sensible default format for
users. Sometimes you want ISO 8601. Sometimes you want whatever your
locale's customary date format is. Sometimes you want US m/d/y dates
for interacting with legacy systems. RFC 2822. RFC 822, natch. And so
on. I don't see why one format should be blessed over others and have
magic behaviour when a DateTime object is cast to a string. IMO, the
fact that users have to provide a format string and call format() is a
good thing: explicit beats implicit, every day of the week.

You absolutely made the case for using DateTime::format() - which is not the
proposal here. This is for a string representation of the object via
toString.

I understand the proposal. My point is that there's no such thing as a
canonical string representation of a DateTime object, and trying to
invent one (or worse, provide yet another configuration option for the
user to choose one in a manner that isn't consistent from installation
to installation) is a pointless exercise.

Anyway, since I understand your argument and simply disagree with it,
I'll wait for the vote.

Adam

13 years ago by Will Fitch — view source — reply

unread

> As far as I can tell, there's no standard which uses the Olson database
> to specify the timezone, so we'd have to create one.
>
> What about ISO8601 with the Olson timezone suffixed?
>
> 2012-09-02T18:17:36+0100 (Europe/London)
> 2012-09-02T18:19:05+0100 (Africa/Niamey)
>

Disagree - The ISO8601 provides a good *string* representation of the
object. If you want every aspect of the entire object, including the
properties which are also objects, serialize it.

>
> --
> Ryan McCue
> <http://ryanmccue.info/

13 years ago by Pierre Joye — view source — reply

unread

hi Will,

>
>
>> As far as I can tell, there's no standard which uses the Olson database
>> to specify the timezone, so we'd have to create one.
>>
>> What about ISO8601 with the Olson timezone suffixed?
>>
>> 2012-09-02T18:17:36+0100 (Europe/London)
>> 2012-09-02T18:19:05+0100 (Africa/Niamey)
>>
>
> Disagree - The ISO8601 provides a good *string* representation of the
> object. If you want every aspect of the entire object, including the
> properties which are also objects, serialize it.

I don't think you will ever get a consensus on that. The reason is
that this case falls in the same fall than the timezone itself (but
per instance of an object instead of globally).

I'd to suggest to force the definition of a format using the
setStringFormat (or whatever will be the name of this function).
__toString will then fail if no format has been set, warning and
returns `NULL` (f.e.).

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Will Fitch — view source — reply

unread

> hi Will,
>
>
> >
> >
> >> As far as I can tell, there's no standard which uses the Olson database
> >> to specify the timezone, so we'd have to create one.
> >>
> >> What about ISO8601 with the Olson timezone suffixed?
> >>
> >> 2012-09-02T18:17:36+0100 (Europe/London)
> >> 2012-09-02T18:19:05+0100 (Africa/Niamey)
> >>
> >
> > Disagree - The ISO8601 provides a good *string* representation of the
> > object. If you want every aspect of the entire object, including the
> > properties which are also objects, serialize it.
>
> I don't think you will ever get a consensus on that. The reason is
> that this case falls in the same fall than the timezone itself (but
> per instance of an object instead of globally).
>
> I'd to suggest to force the definition of a format using the
> setStringFormat (or whatever will be the name of this function).
> __toString will then fail if no format has been set, warning and
> returns `NULL` (f.e.).
>

I actually feel a static function which tracks globally would best serve
this case:

date_default_format_set('c')

This would prevent the need for setting it on a per instance basis -
similar to the way timezones can be set:

date_default_timezone_set('America/Chicago')

>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Benjamin Eberlei — view source — reply

unread

as i said above, a global option will make this feature completly unusable
for libraries. For Doctrine we would really like to have __toString() for
datetime primary keys (identity map), but we need a reliable stable
lossless format that can never change.

>
>
> > hi Will,
> >
> >
> > > On Mon, Sep 3, 2012 at 4:59 AM, Ryan McCue
> wrote:
> > >
> > >> As far as I can tell, there's no standard which uses the Olson
> database
> > >> to specify the timezone, so we'd have to create one.
> > >>
> > >> What about ISO8601 with the Olson timezone suffixed?
> > >>
> > >> 2012-09-02T18:17:36+0100 (Europe/London)
> > >> 2012-09-02T18:19:05+0100 (Africa/Niamey)
> > >>
> > >
> > > Disagree - The ISO8601 provides a good *string* representation of the
> > > object. If you want every aspect of the entire object, including the
> > > properties which are also objects, serialize it.
> >
> > I don't think you will ever get a consensus on that. The reason is
> > that this case falls in the same fall than the timezone itself (but
> > per instance of an object instead of globally).
> >
> > I'd to suggest to force the definition of a format using the
> > setStringFormat (or whatever will be the name of this function).
> > __toString will then fail if no format has been set, warning and
> > returns `NULL` (f.e.).
> >
>
> I actually feel a static function which tracks globally would best serve
> this case:
>
> date_default_format_set('c')
>
> This would prevent the need for setting it on a per instance basis -
> similar to the way timezones can be set:
>
> date_default_timezone_set('America/Chicago')
>
>
> >
> > Cheers,
> > --
> > Pierre
> >
> > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

13 years ago by Derick Rethans — view source — reply

unread

as i said above, a global option will make this feature completly unusable
for libraries. For Doctrine we would really like to have __toString() for
datetime primary keys (identity map), but we need a reliable stable
lossless format that can never change.

Just wondering - would a userland inherited class not work for you?

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

13 years ago by jpauli — view source — reply

unread

Just In Case, I implemented a solution in an extension of mine.
I use a INI setting, ideas are on my github
https://github.com/jpauli/Comuto/blob/master/comuto.c#L97 and
https://github.com/jpauli/Comuto/blob/master/comuto.c#L175

Anyway, I'm really +1 for patching ext/date to add such a feature :)

Julien.P

as i said above, a global option will make this feature completly unusable
for libraries. For Doctrine we would really like to have __toString() for
datetime primary keys (identity map), but we need a reliable stable
lossless format that can never change.

Just wondering - would a userland inherited class not work for you?

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

13 years ago by Pierre Joye — view source — reply

unread

hi!

Just In Case, I implemented a solution in an extension of mine.
I use a INI setting, ideas are on my github
https://github.com/jpauli/Comuto/blob/master/comuto.c#L97 and
https://github.com/jpauli/Comuto/blob/master/comuto.c#L175

Anyway, I'm really +1 for patching ext/date to add such a feature :)

Same here, but an INI setting is a no go :)

Cheers,

Pierre

@pierrejoye

13 years ago by Will Fitch — view source — reply

unread

Peter Cowburn wrote:

Finally, why should "echo $datetime;" be expected to work at all,
since 95% of the time it's only going to be echo'd plain like that for
debugging purposes as we'll never pick the "right" format to use in
everyone's code. When needing to set the "default" (read:
per-instance) string format with something like setToStringFormat() or
whatever, that becomesmore work than just calling format().

Hopefully Will now understands just how problematic his request is, and
why it has not been implemented as yet. I'm with you but for a slightly
different reason. I never run anything but UTC on the server. So I'm only
displaying anything other than UTC when handling a client view of the
data.
So I would normally be calling format with the client timezone data.

It is problematic because that is what we choose to make it. Right now,
a
catchable fatal error is produced. That is problematic. ISO8601 is not
lossy nor is UTC.

This tells me you haven't researched this subject properly. So let me
demonstrate once more:

$d = date_create( "2012-09-03 09:13:52" );
var_dump( $d );
$s = $d->format( DateTime::ISO8601 );
$d = date_create( $s );
var_dump( $d );

Outputs:

class DateTime#1 (3) {
public $date =>
string(19) "2012-09-03 09:13:52"
public $timezone_type =>
int(3)
public $timezone =>
string(13) "Europe/London"
}

class DateTime#2 (3) {
public $date =>
string(19) "2012-09-03 09:13:52"
public $timezone_type =>
int(1)
public $timezone =>
string(6) "+01:00"
}

And voila, you've just lost the timezone that belongs to the DateTime
object.

You have an accurate representation of the ISO format - which does not
specify the string representation of a timezone, but rather the offset of
UTC. This is not lossy. The DateTime object still maintains its integrity

and includes the offset (if present). The toString representation is not
a serialized format of every attachment of the entire object - it's a
string representation.

You actually helped prove the case for ISO-8601, IMHO. You were able to
take the date, time and UTC offset and accomplish the same goal; all of
this from the toString format!

We have standards for a reason. I agree that changing that should not
be allowed. I will remove the set/get pattern functions and only print
a standard format. Printing an ISO standard format, which includes the
TZ based on UTC, or even the UTC format itself is a better solution
than a catchable fatal error.

I disagree as it is an Ostrich Method. Instead of fixing your problem
you'll just be hiding it.

Derick

13 years ago by Derick Rethans — view source — reply

unread

You have an accurate representation of the ISO format - which does not
specify the string representation of a timezone, but rather the offset of
UTC. This is not lossy.

Yes it is! You can't go back from an UTC offset to a timezone string.
Hence: lossy.

cheers,
Derick

13 years ago by Lester Caine — view source — reply

unread

Derick Rethans wrote:

You have an accurate representation of the ISO format - which does not

specify the string representation of a timezone, but rather the offset of
UTC. This is not lossy.
Yes it is! You can't go back from an UTC offset to a timezone string.
Hence: lossy.

Exactly ...

Will - if you are displaying a date, and then looking for a UTC time 6 months
later you need the daylight saving setting. Personally I get around this problem
by displaying a 'local client time' based on extra details provided by the
client login. A server default is never going to be the right answer unless you
simply switch off ALL timezone working and only use local time, in which case
your proposal could work - as long as it NEVER displays offsets. Most problems
on systems that DO require to correctly manage timezone shifted data come about
by not running the server with a fixed UTC clock and then trying to map things
across different timezones. In this situation, the browser time offset is
useless and the main reason that Derick is flagging ISO format as lossy. It can
never give you the correct data in six months time where daylight saving shifts
comes in and using it here is just exacerbating that problem by continuing to
reinforce a wrong 'standard'.

So the server 'default' local time needs to work of extra timezone data rather
than the local clock. Any display MUST then show timezone rather than just an
arbitrary offset or simply UTC time ... with a UTC flag to confirm that.

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

13 years ago by Will Fitch — view source — reply

unread

Derick Rethans wrote:

You have an accurate representation of the ISO format - which does not

specify the string representation of a timezone, but rather the offset
of
UTC. This is not lossy.

Yes it is! You can't go back from an UTC offset to a timezone string.
Hence: lossy.

Exactly ...

Will - if you are displaying a date, and then looking for a UTC time 6
months later you need the daylight saving setting. Personally I get around
this problem by displaying a 'local client time' based on extra details
provided by the client login. A server default is never going to be the
right answer unless you simply switch off ALL timezone working and only use
local time, in which case your proposal could work - as long as it NEVER
displays offsets. Most problems on systems that DO require to correctly
manage timezone shifted data come about by not running the server with a
fixed UTC clock and then trying to map things across different timezones.
In this situation, the browser time offset is useless and the main reason
that Derick is flagging ISO format as lossy. It can never give you the
correct data in six months time where daylight saving shifts comes in and
using it here is just exacerbating that problem by continuing to reinforce
a wrong 'standard'.

So the server 'default' local time needs to work of extra timezone data
rather than the local clock. Any display MUST then show timezone rather
than just an arbitrary offset or simply UTC time ... with a UTC flag to
confirm that.

Hi, Lester - I'll update the patch and RFC to include this format. This is
the format I'll use unless others have a better approach:

2012-09-01T00:00:00-0500 (America/Chicago)

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=**contact http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.**uk<http://rainbowdigitalmedia.co.uk

13 years ago by Lester Caine — view source — reply

unread

Andrew Faulds wrote:

Yes, I am saying that ISO8601 is lossy - and that is something that
shouldn't be the default format.

Lossy of what? Local timezone?

ISO 8601 is the single unambiguously ordered (no mm-dd/dd-mm confusion),
international standard, machine-readable (default in ECMAScript, for instance)
date/time format.

I see no reason not to use it. Date/time should be UTC anyway when debugging.

ACTUALLY - you need to define which of the various ISO8601 versions you do want
to use. It's not a SINGLE format style anyway.
http://www.cl.cam.ac.uk/~mgk25/iso-time.html

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

13 years ago by Will Fitch — view source — reply

unread

No it's not unambigious:

$ php -r 'date_default_timezone_set("Europe/London"); echo
date_create()->format(DateTime::ISO8601), "\n";'
2012-09-02T18:17:36+0100

$ php -r 'date_default_timezone_set("Africa/Niamey"); echo
date_create()->format(DateTime::ISO8601), "\n";'
2012-09-02T18:19:05+0100

vs:

$ php -r 'date_default_timezone_set("Africa/Niamey"); echo
date_create("2012-12-31")->format(DateTime::ISO8601), "\n";'
2012-12-31T00:00:00+0100
^^^^^

$ php -r 'date_default_timezone_set("Europe/London"); echo
date_create("2012-12-31")->format(DateTime::ISO8601), "\n";'
2012-12-31T00:00:00+0000
^^^^^

I'm a little confused as to what is going on here, but ISO8601 has a UTC
format, YYYY-MM-DDTHH:MM:SSZ.

I think the issue on most minds is the TZ aspect. I agree with the others
on using UTC. I also think ill suggest a different approach to this.

cheers,
Derick

--
Andrew Faulds
http://ajf.me/

13 years ago by Derick Rethans — view source — reply

unread

No it's not unambigious:
..snip...

I'm a little confused as to what is going on here, but ISO8601 has a UTC
format, YYYY-MM-DDTHH:MM:SSZ.

I think the issue on most minds is the TZ aspect. I agree with the others
on using UTC.

That loses even more information, so I disagree with that even more.

cheers,
Derick

13 years ago by Sherif Ramadan — view source — reply

unread

It is problematic because that is what we choose to make it. Right now, a
catchable fatal error is produced. That is problematic. ISO8601 is not
lossy nor is UTC. It can be taken by any other language and converted based
on the format itself.

I don't understand why that's problematic? The user wants to output a
formated date they should provide a format by calling
DateTime::format()... why do we have to assume the user will find
any standards we propose to be acceptable? As you can see everyone
here that uses it expects something slightly different. This request
makes no sense. Sorry.

We have standards for a reason. I agree that changing that should not be
allowed. I will remove the set/get pattern functions and only print a
standard format. Printing an ISO standard format, which includes the TZ
based on UTC, or even the UTC format itself is a better solution than a
catchable fatal error.

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

13 years ago by Will Fitch — view source — reply

unread

Hi Pierre, hi Will,

Am 03.09.2012 um 13:57 schrieb Pierre Joye pierre.php@gmail.com:

hi Will,

As far as I can tell, there's no standard which uses the Olson database
to specify the timezone, so we'd have to create one.

What about ISO8601 with the Olson timezone suffixed?

2012-09-02T18:17:36+0100 (Europe/London)
2012-09-02T18:19:05+0100 (Africa/Niamey)

[...]

I don't think you will ever get a consensus on that. The reason is
that this case falls in the same fall than the timezone itself (but
per instance of an object instead of globally).

I'd to suggest to force the definition of a format using the
setStringFormat (or whatever will be the name of this function).
__toString will then fail if no format has been set, warning and
returns NULL (f.e.).

I don’t agree here, especially if we recap what the proposed purpose of
the __toString() method was:

Ease debugging by allowing "echo $date;" instead of "echo
$date->format(...);"

An additional constraint to make sure users use it for debugging and
nothing else, would be:

Not allow changing the format, neither by ini setting or any other
global means (incl. setters)

To achieve that, we need a time format that is best for debugging,
meaning, as lossless as possible. While ISO8601 comes pretty close it
misses out on the Olson timezone suffix. I would second the notion of
creating our own format and standardizing it internally with it’s own
constant and DateTime doing the right thing if passed to the constructor.
Additionally to what Ryan proposed, microseconds should be part of it
(which ISO allows). So, here we go:

2012-09-02T18:17:36.12345+0100 (Europe/London)

Hi, Lars - there wouldn't be a need for the offset if the string provides
the timezone name. Parsing this wouldn't be an issue, however, it would be
harder to sell this approach to others.

Following this, the change would be fairly easy (adding a constant, a bit
parsing fu and the toString() method).

cu,
Lars

13 years ago by Derick Rethans — view source — reply

unread

Additionally to what Ryan proposed, microseconds should be part of it
(which ISO allows). So, here we go:

2012-09-02T18:17:36.12345+0100 (Europe/London)

Hi Lars - there wouldn't be a need for the offset if the string
provides the timezone name.

And you are wrong again:

<?php
$d = date_create( "@1351385100" );
$d->setTimeZone( new DateTimeZone( 'Europe/London' ) );
echo $d->format( 'Y-m-d H:i:s (e)' ), "\n";

$d = date_create( "@1351388700" ); // one hour later
$d->setTimeZone( new DateTimeZone( 'Europe/London' ) );
echo $d->format( 'Y-m-d H:i:s (e)' ), "\n";

outputs:

2012-10-28 01:45:00 (Europe/London)
2012-10-28 01:45:00 (Europe/London)

And it's clearly not the same moment in time...

Parsing this wouldn't be an issue,

It is an issue - there is even an RFC (that I still need to implement)
for it: https://wiki.php.net/rfc/datetime_and_daylight_saving_time

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

13 years ago by Pierre Joye — view source — reply

unread

hi Lars,

Ease debugging by allowing "echo $date;" instead of "echo $date->format(...);"

Ooch. If that's the only goal, it makes no sense to add that.

However I see many useful usages like passing date object to templates
and the likes (while tpl system can implement it cleanly too, but it
spares some code duplication all over the apps).

Cheers,

Pierre

@pierrejoye

13 years ago by Lester Caine — view source — reply

unread

Will Fitch wrote:

Hi, Lester - I'll update the patch and RFC to include this format. This is the
format I'll use unless others have a better approach:

2012-09-01T00:00:00-0500 (America/Chicago)

Either offset OR timezone ... not both ... BUT as Derick has pointed out ...
without the offset, we don't know it is offset from UTC so you end up needing
both. This is where there is still a lot of disagreement on short codes for
normal and DST settings and a lot of clashes. NORM/DST is more help than the
offset ... ( And seconds for Lars )

However the other thing to bear in mind here is that if you don't set a timezone
for the datetime object then you just get a simply local time and do not want to
display a timezone at all. I think it more likely that people will be doing that
as much as are actually displaying a timezone? I would probably expect as many
people don't want TZ as do? Derick will probably say you should not use it like
that ;) but I only setTimezone on the display side when I need to convert from
UTC. Simple single time zone setups don't need to worry about daylight saving so
just working with a simple 'clock' is practical.

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

13 years ago by Lester Caine — view source — reply

unread

Will Fitch wrote:

Hi, Lester - I'll update the patch and RFC to include this format. This is the
format I'll use unless others have a better approach:

2012-09-01T00:00:00-0500 (America/Chicago)

Just working through another backlog of 'todo' items.

Your current RFC includes -0500 in the examples, but that is purely due to your
own setup. This is the real problem here since you can't take a date/time string
and clone a new object. You have to define a DateTimeZone object prior to
creating the DateTime object. You have 'America/Chicago' set as your default
timezone, and that is fine for your local working, but part of Derick's
objection is that how this all hangs together is always a two stage process.

Now if you can make the above string clone a matching DateTime/DateTimeZone
object pair, then part of the objection would go, but I would still object to
any default here since it's just as likely you want to leave the timezone off
and handle it separately as include it in an output string.

Also it is worth noting that DateTime::__construct specifically ignores the
$timezone parameter when the date string includes an offset! This may well be
considered a bug and perhaps $timezone parameter should take priority, but it's
all these little things that get missed when one 'just fills in a missing
function' ... someone just taking the default string and trying to create a new
date object for a different timezone might get caught out, so that particular
point should be included in any documentation. Actually currently the returned
string would not work anyway?

The RFC is 'needs more work' but I still feel that adding this 'shortcut' will
create more problems than it will provide any benefit.

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

13 years ago by Will Fitch — view source — reply

unread

Will Fitch wrote:

Hi, Lester - I'll update the patch and RFC to include this format. This
is the
format I'll use unless others have a better approach:

2012-09-01T00:00:00-0500 (America/Chicago)

Just working through another backlog of 'todo' items.

Your current RFC includes -0500 in the examples, but that is purely due to
your own setup. This is the real problem here since you can't take a
date/time string and clone a new object. You have to define a DateTimeZone
object prior to creating the DaTime object. You have 'America/Chicago' set
as your default timezone, and that is fine for your local working, but part
of Derick's objection is that how this all hangs together is always a two
stage process.

Now if you can make the above string clone a matching
DateTime/DateTimeZone object pair, then part of the objection would go, but
I would still object to any default here since it's just as likely you
want to leave the timezone off and handle it separately as include it in an
output string.

Also it is worth noting that DateTime::__construct specifically ignores
the $timezone parameter when the date string includes an offset! This may
well be considered a bug and perhaps $timezone parameter should take
priority, but it's all these little things that get missed when one 'just
fills in a missing function' ... someone just taking the default string and
trying to create a new date object for a different timezone might get
caught out, so that particular point should be included in any
documentation. Actually currently the returned string would not work anyway?

The format being suggested (ISO8601 + TZ name) won't work without
addressing the concern you mentioned as well as correctly parsing the TZ
name.

The RFC is 'needs more work' but I still feel that adding this 'shortcut'
will create more problems than it will provide any benefit.

I'm currently working on revamping the RFC and offering up two separate
solutions. You are right that it's going to be difficult to please
everyone, but I do want a solution that can be acceptable to most. If that
ends up being no solution at all, so be it. I do believe through enough
conversation and potentially adjusting DateTime's current behavior (e.g.
the TZ point you brought up), a solution can be reached.

It's important to keep one of Derick's points in mind as well -
https://wiki.php.net/rfc/datetime_and_daylight_saving_time.

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=**contact http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.**uk<http://rainbowdigitalmedia.co.uk

13 years ago by Lester Caine — view source — reply

unread

Will Fitch wrote:

On Wed, Sep 5, 2012 at 4:14 AM, Lester Caine <lester@lsces.co.uk
mailto:lester@lsces.co.uk> wrote:
Will Fitch wrote:

    Hi, Lester - I'll update the patch and RFC to include this format.  This
    is the
    format I'll use unless others have a better approach:

    2012-09-01T00:00:00-0500 (America/Chicago)

Just working through another backlog of 'todo' items.

Your current RFC includes -0500 in the examples, but that is purely due to
your own setup. This is the real problem here since you can't take a
date/time string and clone a new object. You have to define a DateTimeZone
object prior to creating the DaTime object. You have 'America/Chicago' set
as your default timezone, and that is fine for your local working, but part
of Derick's objection is that how this all hangs together is always a two
stage process.

Now if you can make the above string clone a matching DateTime/DateTimeZone
object pair, then part of the objection would go, but *I* would still object
to any default here since it's just as likely you want to leave the timezone
off and handle it separately as include it in an output string.

Also it is worth noting that DateTime::__construct specifically ignores the
$timezone parameter when the date string includes an offset! This may well
be considered a bug and perhaps $timezone parameter should take priority,
but it's all these little things that get missed when one 'just fills in a
missing function' ... someone just taking the default string and trying to
create a new date object for a different timezone might get caught out, so
that particular point should be included in any documentation. Actually
currently the returned string would not work anyway?
The format being suggested (ISO8601 + TZ name) won't work without addressing the
concern you mentioned as well as correctly parsing the TZ name.
The RFC is 'needs more work' but I still feel that adding this 'shortcut'
will create more problems than it will provide any benefit.
I'm currently working on revamping the RFC and offering up two separate
solutions. You are right that it's going to be difficult to please everyone,
but I do want a solution that can be acceptable to most. If that ends up being
no solution at all, so be it. I do believe through enough conversation and
potentially adjusting DateTime's current behavior (e.g. the TZ point you brought
up), a solution can be reached.

It's important to keep one of Derick's points in mind as well -
https://wiki.php.net/rfc/datetime_and_daylight_saving_time.

That is actually part of the reason all my internal processing is only ever UTC.
so I only use the timezone to display data so does not affect you on that side.
However I know that there is a black hole if someone does try and enter a date
and time in that 1 hour missing window :)

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

RFC for Adding __toString to DateTime

Cheers,

Cheers,

-- Lester Caine - G8HFL

Cheers,

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

Cheers,

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

Cheers,

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL