Unit tests should use a default timezone other that UTC

Thought would need to go into whether a large positive value or a large negative value make more sense for finding potential bugs.

The list of timezones is finite: http://us.php.net/manual/en/timezones.php

The db that is used can be consulted in PECL's » timezonedb, so I downloaded that and it has a header file where all possibilities are listed. There, you can see the exact values.

{ "Africa/Abidjan"                    , 0x000000 },
{ "Africa/Accra"                      , 0x0000B6 },
...
{ "Asia/Tokyo"                        , 0x0520C2 },
...
{ "UTC"                               , 0x0A9120 },
{ "W-SU"                              , 0x0A9908 },
{ "WET"                               , 0x0A91AB },
{ "Zulu"                              , 0x0A9F0C },

These are values between 0 and 696076, so we definitely don't want to choose a negative value.

Then, looking at http://us.php.net/manual/en/timezones.others.php we can see that some timezones only are listed for backwards compatibility but shouldn't be used (e.g. WET and ZULU).

In conclusion, "Asia/Tokyo" as proposed in #1 is as good as any. And choosing something far away from the default UTC seems the sane thing to do. So let's keep that.

Yes, but that would be the number that is internally used by PECL? I think I've misunderstood the thing to research completely...

Judging from "related to the offset", did you mean something more like:

If we look at a list of timezones, and we find:

'Asia/Tokyo' => "(GMT+09:00) Tokyo",

Then the question is whether or not we want to use something more "edge case like", e.g.:

'Pacific/Midway' => "(GMT-11:00) Midway Island",
or
'Pacific/Fiji' => "(GMT+12:00) Fiji",

In that case I'm not sure if it would make a big difference in finding bugs, but it couldn't harm us to choose Pacific/Kiritimati (UTC+14:00). They are the first to reach a new day.

Fwiw, on the other far edge we have UTC-12:00, which (TIL) apparently is only used by ships.

Ok, so here goes:

UTC-12: seems not to have a readable alias
UTC-11: Pacific/Midway

UTC+11: Asia/Magadan
UTC+11:30: Pacific/Norfolk
UTC+12: Pacific/Auckland
UTC+12:45: Pacific/Chatham
UTC+13: Pacific/Tongatapu
UTC+14: Pacific/Kiritimati

Well, that's an interesting result.

The "extra fails" for Asia/Magadan are:

('10 years', 1071097748, 1386713348) Exception: Expected: 10 years | Diff: 9 years 11 months
('100 years', -1769039644, 1386713348) Exception: Expected: 100 years | Diff: 99 years 11 months

The other "extra fails" are similar.

It seems like the one we are looking for is "Asia/Magada" then?

None of these timezones use DST, however all of them experimented with the concept. Based on the info on timezoneconvertor.com and wikipedia.org, it seems that these changes at least correlate with the extra failures.

UTC-11: Pacific/Midway: DST ended on Wed 30-Nov-1983 with no actual change change -> no extra failure
UTC+11: Asia/Magadan: Moscow+08 (Moscow+07 after 2014-10-26) -> failure for 10 years and 100 years
UTC+11:30: Pacific/Norfolk: DST ended on Mon 1-Jan-1951, 18 minutes forward-> failure for 100 years
UTC+12: Pacific/Auckland: DST ended on Sun 5-Apr-2015, backward 1 hour -> no extra failure
UTC+12:45: Pacific/Chatham: DST ended on Sun 5-Apr-2015, backward 1 hour -> no extra failure
UTC+13: Pacific/Tongatapu: DST ended on Sun 27-Jan-2002, 1 hour backwards -> failure for 100 years
UTC+14: Pacific/Kiritimati: DST ended on Sun 1-Jan-1995 with no actual change -> failure for 100 years

I can reproduce these failures on my local machine. According to phpinfo(), it uses the system timezone information (so not the pecl timezonedb). If my timezone database version was build between 10/2014 and 04/2015 (not sure how to check), then the extra failures seem to be caused by these jumps in time.

So to get back to the question at hand, if we want edge case we could pick one with historical changes in DST and fix the test accordingly. However, I don't think fixing the failures would look very logical. Someone just browsing the test would definitely not get that. That makes me lean towards using "Pacific/Midway".

Note that all this commotion is caused by a single function call. Do we have use cases other than diff()?

As for the diff() function itself, we could also look to a timezone that uses DST? If we do that, we should expand the test coverage in datetest, to test all months in a certain year. We don't have that now.

These are two examples that have DST:
- America/Los_Angeles: −08:00 (DST is −07:00)
- America/Denver: −07:00 (DST is −06:00)

I don't think we want a super edge case, so I'd say we pick one with DST.

Added beta eval.

Ok, sure!

Fair enough. How about we borrow some text from the IS?