Yii2: Inconsistent asTimestamp

Created on 11 Apr 2016  路  9Comments  路  Source: yiisoft/yii2

Issue reported by @stiff-dev
Timestamp formatter returns value based on defaultTimeZone which is inconsistent with other date & time formatters (case A) OR wrong in general (case B).
In case A I expect timestamp formatted according to the set time zone (weird but consistent).
In case B I expect timestamp formatted according to the UTC (timezone independent just like time())

What steps will reproduce the problem?

Yii::$app->formatter->timeZone = 'UTC';
Yii::$app->formatter->defaultTimeZone = 'UTC';

echo 'T1: ' . Yii::$app->formatter->asTimestamp('2016-04-11 14:36') . '<br>';

Yii::$app->formatter->timeZone = 'Europe/Warsaw';
Yii::$app->formatter->defaultTimeZone = 'UTC';

echo 'T2: ' . Yii::$app->formatter->asTimestamp('2016-04-11 14:36') . '<br>';

Yii::$app->formatter->timeZone = 'Europe/Warsaw';
Yii::$app->formatter->defaultTimeZone = 'Europe/Warsaw';

echo 'T3: ' . Yii::$app->formatter->asTimestamp('2016-04-11 14:36') . '<br>';

Yii::$app->formatter->timeZone = 'UTC';
Yii::$app->formatter->defaultTimeZone = 'Europe/Warsaw';

echo 'T4: ' . Yii::$app->formatter->asTimestamp('2016-04-11 14:36') . '<br>';

What is the expected result?

Case A:
T1: 1460385360
T2: 1460378160
T3: 1460378160
T4: 1460385360

Case B:
T1: 1460385360
T2: 1460385360
T3: 1460385360
T4: 1460385360

What do you get instead?

T1: 1460385360
T2: 1460385360
T3: 1460378160
T4: 1460378160

Additional info

| Q | A |
| --- | --- |
| Yii version | 2.0.7 |
| PHP version | Win: 5.5.12 Linux: 5.5.9 |
| Operating system | Windows 7, Linux Mint 17.3 Rosa |

I think case B should be used here.

bug

Most helpful comment

Wait, need a closer look.

All 9 comments

This is expected result: if you specify date 2016-04-11 14:36 with timezone set to 'Europe/Warsaw' it will be formatted as timestamp for 2016-04-11 13:36 at UTC.
Timezone setting works in both ways: formatting timestamp as date and creating timestamp from date.

Wait, need a closer look.

No, behavior is correct.
Timestamp value is universal and does not depend on timezone during formatting.
Thus only defaultTimeZone parameter matters in your examples: ite determines which time is used for the source string, however it does not matter which timezone is output one.

You described how it works now but I'm not sure if it's right. I expect this value to be time zone independent (defaultTimeZone independent in this case).
Anyway, it might be a good idea to state in docs that it returns timestamp in defaultTimeZone.

it might be a good idea to state in docs that it returns timestamp in defaultTimeZone

Once again: there is NO timezone for the timestamp! Timestamp is the way of time representation, which is INDEPENDENT from timezone. That is why it is so widely used for the time storage.

There is nothing to be documented - this is basic time processing knowledge.

Then why defaultTimeZone matters, if timestamp is independent from timezone?

Timezone DOES matter while parsing string time representation, like 2016-04-11 14:36.
At UTC timezone such string matches timestamp1, while in 'Europe/Warsaw' it matches timestamp2.

Yes, that's the thing I know already. Let's look at the example.
User gives me datetime's string 2016-04-11 14:36. I want to save this datetime in timestamp to my database. He is in UTC+2 aka 'Europe/Warsaw' timezone. Should I use asTimestamp() to generate wanted timestamp? If I do so, without setting defaultTimeZone I get this time as in UTC, so when I want to print it (using asDatetime()) it formats this timestamp using UTC+2 offset, so I get wrong hour. Should it be this way? Or should all formatter's methods use the same timezone?

short presentation of a problem
user gives 2016-04-11 14:36 -> saving timestamp from asTimestamp() -> getting string from asDatetime() -> gets 2016-04-11 16:36

I confirm this indeed works as intended (sorry for bothering).
We were confused by different timezone settings.

@stiff-dev example:
To get expected values both timezones (used and default) must be the same (or at least represent the same time offset).

Was this page helpful?
0 / 5 - 0 ratings