Wrong timestamp on snaphot
-
Hi
Wrong timestamp on snapshot - in my case 2h offset, can someone explain it to me how it can not be an issue where I take xcp-ng install cd and install it on hardware, then inporting xoa, then make few vms, in meantime xcp and xoa are updating (so we have latest versions), then i take a snapshot of a vm and have have wrong timestamp in vm shapshot comparing to real time and time presented in xoa vm root.
-
why there is (2)h offset? The time checked on xoa vm root is corrent, but the vm snap name have (hours) offset. So from where xoa takes the time that later is in the snapshot name?
-
this is an issue, this is happening out of the box.
-
-
As we already explained multiple times, snapshot timestamp is in UTC (hence the "Z", stands for Zulu time, which is also GMT and UTC)
The Z suffix in the ISO 8601 time representation is sometimes referred to as "Zulu time" because the same letter is used to designate the Zulu time zone
-
How to fix it? The time on snapshot should be the same as local time.
-
Fix what? It's not a bug.
-
Sometimes I just can't understand some things...
So again - If its not a bug, why the timestamp is wrong comparing to local time?
-
No worries, I'll re-explain
A timestamp is a timestamp (eg a number of sec since Jan 1st 1970 for UNIX timestamp) . There's no wrong or right.
Why your timezone will be more right than any other? Imagine you have a another admin doing backups in another TZ, what we should do? Who's right? who's wrong? And what if a third admin in another TZ will read snapshot time? This will be a mess.
So we decided to use the Zulu time, because it's universal and everybody can convert it on its local time.
Anyway, Zulu time is not wrong, is one representation of time that's universal
Did you spotted the "Z" in it?
-
@olivierlambert said in Wrong timestamp on snaphot:
Imagine you have a another admin doing backups in another TZ
So this is the problem - I don't and will not have a backups in another timezone, I want to have correct time on the snapshot - so can It be done?
-
Sometimes I wonder if you read my answers
-
@olivierlambert Always, So - again - can I have correct time in snapshot or no? I want the timestamp on snapshot to match local time of xoa, can It be done - this is simple as that
-
You have the correct time. There's a 'Z' in it. So it is correct. Period.
The only thing I can imagine to have this info both universal and not confusing would be to add an "overlay" in the web client to adapt to your own local TZ without modifying the info on the host side. But we must store the info in the most universal way possible (eg if you use
xe
CLI, it will display the original info in zulu time, and you'll continue to say it's wrong despite the fact I explained 10 times why it's not) -
@olivierlambert said in Wrong timestamp on snaphot:
You have the correct time. There's a 'Z' in it. So it is correct. Period.
I agree with that and I totally understand it. The question in can I (or Your team) make some adjustments in xo/a to see the exact the same which is on xoa host and on vm snap?
-
@akurzawa said in Wrong timestamp on snaphot:
I agree with that and I totally understand it.
Great!!!
The question in can I (or Your team) make some adjustments in xo/a to see the exact the same which is on xoa host and on vm snap?
As I said, even if we don't that (as a "lying" UI to replace to your local timestamp), this won't change the data storage in the XAPI field. But I wonder if it's a good idea.
-
Hi
It'a an important to know exact time of vm and snapshot - eg when recovering for an example a Active Directory or sql database. When doing so, someone can believe that restores the data from {the time visible in name}, because can be unaware of possible offset of zulu time.
-
@akurzawa Which version of XO are you using? If open source one, I guess it should be straight to make it suite your needs. Or may be you tried that but had issue?
-
@akurzawa said in Wrong timestamp on snaphot:
Hi
It'a an important to know exact time of vm and snapshot - eg when recovering for an example a Active Directory or sql database. When doing so, someone can believe that restores the data from {the time visible in name}, because can be unaware of possible offset of zulu time.
You already have the exact time If you aren't aware of an ISO standard format date, it's another story. But this is really standard and universal way.
I suppose you meant "misinterpreting the snapshot time" which has NOT the same meaning than "incorrect time".