A timestamp is a piece of data that records when a particular event happens. Originally the term applied to documents which were actually stamped with an ink stamp that contained a clock that would stamp the approximate time on a document. While you still see physical timestamps on postmarks, the term more commonly refers to digital timestamps, a string of characters (or just raw bytes) that encodes where a file was created or modified (or sometimes when it was last accessed).
Timestamps are a bit of a mess on the internet. There are many things that can go wrong with them, and because of this it's quite common for false claims of evidence (bunk) to arise from the use of timestamps. In particular the common claim is made that a particular web page (or image, or video), supposedly of a particular event, is dated before that event, and this is then evidence that the event was faked, or planned in advance.
This article will explain how timestamps work, how they are frequently wrong, and what you can do to try to determine if they are wrong, and what the actual date it. I'll also discuss the limits of these techniques. This is written from the perspective of a debunker, so mostly reflects all the things I've learned while doing my debunking.
In order to really understand what you are doing, it's very helpful to have an understanding of time zones, and UTC. You can get a basic understanding of the issue without it, but for any detailed investigation then it's going to be essential. I'm going to labor these points, but it's very easy to slip up and add instead of subtract, or miss daylight savings time, or get the actual day wrong, so it's good to have a full understanding of the issues.
Time Zones and UTC
Source: Wikipedia/TimeZonesBoy
Most people are familiar with the fact that time is different in different parts of the world. But their practical understanding of this will vary by where they live. In the UK most people have little use for different time zones. In the US, with four time zones on the mainland, the understanding is largely reduced to the difference between the local time zone, and the Eastern and Pacific time zones. This is largely due to the timing of live TV events, with the time often given in both, like "12 Eastern, 9 Pacific", a phrase that will be familiar to most TV viewers in the US.
But when it comes to converting one time zone to another, particularly in another part of the world, it can get quite head-scratching confusing. If it's not something like UK Time vs. Western Europe, or Eastern vs. Pacific US times, then frequently the best way of figuring out what time it actually is, is to use the universal time standard, UTC (Coordinated Universal Time).
UTC is essentially the same as GMT (Greenwich Mean Time, the time the UK uses in winter). It's not really a time zone itself, but instead the standard time from which all other time zones are relative to. Generally any time zone can be described as being UTC, plus or minus a number of hours (there are a few that use half hours, but they rarely come up). GMT is a time zone, but with an offset of 0, so you could say GMT is UTC+0
(It's is very important to avoid using GMT interchangeably with UTC, as some people think "GMT" means "UK Time", and so they use GMT in the summer when they really should be using BST. You be aware that this mistake happens, and try to avoid it by only using UTC)
UTC is particularly useful in observing aviation, such as with plane and contrail spotting, since a large proportion of planes fly through multiple time zones, but the observations are made in local time zones. The simplest thing to do it to use UTC as much a possible, and convert your local time to UTC.
Converting times via UTC
All time zones have a name, and usually a three (or four) letter abbreviation. They also have an offset from UTC. Here's some examples:
You've also got to be careful with Daylight Savings Time. The West of the US is listed as UTC-8 on the chart above, as that's the Pacific Standard Time. But PST only runs for three months of the year, from December to January. So for most of the year the west coast is on UTC-7. And not all places have Daylight Savings Time. Japan, for example, only has JST, year round. (Very sensible, in my opinion)
Now to convert from one time zone to another, you first convert from the first time zone to UTC (meaning you apply the opposite offset), and then you convert from UTC to the second time zone. For example, to convert from 0600 (6AM) PDT (-8) to JST (+9), we do:
Notice a few things here. Firstly I'm using a 24 hour clock which goes from 0000 (00h 00m) which is midnight, or 12:00AM , to 2359 (23h 59m) which is 11:59PM. The reason being that it's much easier to work with a single number than a number and an AM/PM signifier. UTC is almost always represented in 24 hour format.
Secondly I did it in two steps, where you could do it in (kind of) one. Like: new time = time + (offset2 - offset1), or in this case new time = time + (9 - -7) or time + 16. This is of course the exact mathematical equivalent of what we just did, but without calculating the UTC time. However I'd encourage you to use the via-UTC method, as most of the time you'll want to know the UTC time anyway.
Thirdly, converting from Los Angeles time (PDT) to Tokyo time meant adding 16 hours. Is that the same as subtracting 6 hours? At 6PM in Los Angeles, then Tokyo is at 12PM, so are they not just 6 hours behind us? No, and this is very important, they are 16 hours ahead of us, which generally mean they are in the next day.
The International Dateline and the Sweeping Midnight Line
Assuming a straightforward 24 time zones, then for 23 out of every 24 hours there are two days on the planet. When investigating timestamps it's important to know which one of those two days the timestamp is in, especially if you convert from one timezone to another.
Everyone knows there's an International Dateline, and we've heard that you can gain or lose a day by traveling over it. But the dateline is of surprising little importance in date analysis. The more important thing is the Midnight Line.
The midnight line is the western edge of the time zone that's in the hour directly after midnight (i.e 0000 to 0059, or midnight to 1AM). To the west of the midnight line it's one day, and to the east it's the next day. Every hour the line jumps one time zone to the west. When the midnight line gets past Alaska to the international date line then for one hour all the time zones in the world are in the same day. Then an hour later the midnight line jumps over the international date line and it's 0000 (midnight, 12AM) on the next day in the first significant time zone at UTC+12 in New Zealand, which is why they get to celebrate the New Year first.
Unfortunately there's a kink in matters in that there's more than 24 time zones, and more than 24 possible times used in those. There's actually UTC+14 used by some pacific island. This means that they see the new day (and new year), a full hour ahead of New Zealand, who are actually on Daylight Savings Time at New Year, so are in UTC+13
And in the other direction (but about the same longitude), we have UTC-12, when the lowest offset should have been UTC-11 (the range is -11 to +12, which including 0 gives you 24 zones). Luckily UTC-12 is only technically used on a couple of uninhabited islands, so is unlikely to be an issue. But even with UTC-11 to UTC+14, that still means it's possible to have three calendar dates on the planet at the exact same time, which add an occasional complication to time zone conversions.
Here's a great overview of the history and complexity of odd time zones.
When do you add or subtract a day (or two) when converting times between zones?
You add a day if when adding an offset you go past midnight from one day to the next.
You subtract a day if when subtracting an offset you go past midnight from one day to the previous.
Pretty obvious really. And the reason the international dateline does not come into effect is that we are always doing our offset via UTC. Since the UTC line goes through London, and that's on the opposite side of the globe to the International Date Line, then we never cross the dateline, and the days all work out.
The only (very rare) complication might be at UTC+14. To go from UTC-11 to UTC+14, that's +25 hours. So if you are at 23:30 on a Sunday in American Samoa, then you pass the midnight line twice on your travel to 00:30 on a Tuesday on the Island of Kiribati (while it's Monday in most of the rest of the world.
How Time Zone confusion can introduce errors.
It's clear from the long description I had to give above that there's a lot of potential for errors to be introduced into a timestamp when converting time zones. The good news is that most of the internet timestamps are actually stored in UTC/GMT. The most common way of storing a timestamp is to use Unix Time, which is "simply" the number of seconds that have elapsed since 00:00:00 UTC on January 1 1970. Other than some ambiguity over leap seconds, this is essentially UTC.
The problem is that Unix Time is just a number of seconds, like 14335494425 (the time I typed that sentence). It's not human readable. The actual date it represents is 06/06/2015 00:10:25 UTC. The number has to be both converted into a readable time and date, and then displayed in the way the user expects, which is normally in their own time zone. So for me, I would want to see 17:10:25, or 5:10PM.
[To be continued]
Additional reading:
https://www.metabunk.org/how-to-find-the-exact-upload-time-of-a-facebook-photo.t4367/
https://www.metabunk.org/debunked-m...re-the-crash-and-other-timeline-issues.t3988/
Timestamps are a bit of a mess on the internet. There are many things that can go wrong with them, and because of this it's quite common for false claims of evidence (bunk) to arise from the use of timestamps. In particular the common claim is made that a particular web page (or image, or video), supposedly of a particular event, is dated before that event, and this is then evidence that the event was faked, or planned in advance.
This article will explain how timestamps work, how they are frequently wrong, and what you can do to try to determine if they are wrong, and what the actual date it. I'll also discuss the limits of these techniques. This is written from the perspective of a debunker, so mostly reflects all the things I've learned while doing my debunking.
In order to really understand what you are doing, it's very helpful to have an understanding of time zones, and UTC. You can get a basic understanding of the issue without it, but for any detailed investigation then it's going to be essential. I'm going to labor these points, but it's very easy to slip up and add instead of subtract, or miss daylight savings time, or get the actual day wrong, so it's good to have a full understanding of the issues.
Time Zones and UTC
Source: Wikipedia/TimeZonesBoy
Most people are familiar with the fact that time is different in different parts of the world. But their practical understanding of this will vary by where they live. In the UK most people have little use for different time zones. In the US, with four time zones on the mainland, the understanding is largely reduced to the difference between the local time zone, and the Eastern and Pacific time zones. This is largely due to the timing of live TV events, with the time often given in both, like "12 Eastern, 9 Pacific", a phrase that will be familiar to most TV viewers in the US.
But when it comes to converting one time zone to another, particularly in another part of the world, it can get quite head-scratching confusing. If it's not something like UK Time vs. Western Europe, or Eastern vs. Pacific US times, then frequently the best way of figuring out what time it actually is, is to use the universal time standard, UTC (Coordinated Universal Time).
UTC is essentially the same as GMT (Greenwich Mean Time, the time the UK uses in winter). It's not really a time zone itself, but instead the standard time from which all other time zones are relative to. Generally any time zone can be described as being UTC, plus or minus a number of hours (there are a few that use half hours, but they rarely come up). GMT is a time zone, but with an offset of 0, so you could say GMT is UTC+0
(It's is very important to avoid using GMT interchangeably with UTC, as some people think "GMT" means "UK Time", and so they use GMT in the summer when they really should be using BST. You be aware that this mistake happens, and try to avoid it by only using UTC)
UTC is particularly useful in observing aviation, such as with plane and contrail spotting, since a large proportion of planes fly through multiple time zones, but the observations are made in local time zones. The simplest thing to do it to use UTC as much a possible, and convert your local time to UTC.
Converting times via UTC
All time zones have a name, and usually a three (or four) letter abbreviation. They also have an offset from UTC. Here's some examples:
- PST - Pacific Standard Time - UTC -8:00
- PDT - Pacific Daylight Time - UTC -7:00
- EST - Eastern Standard Time - UTC -5:00
- JST - Japan Standard Time - UTC +9:00
You've also got to be careful with Daylight Savings Time. The West of the US is listed as UTC-8 on the chart above, as that's the Pacific Standard Time. But PST only runs for three months of the year, from December to January. So for most of the year the west coast is on UTC-7. And not all places have Daylight Savings Time. Japan, for example, only has JST, year round. (Very sensible, in my opinion)
Now to convert from one time zone to another, you first convert from the first time zone to UTC (meaning you apply the opposite offset), and then you convert from UTC to the second time zone. For example, to convert from 0600 (6AM) PDT (-8) to JST (+9), we do:
- 0600 PDT (UTC-7) apply opposite offset, so +7, so 1300 UTC
- 1300 to JST (UTC+9), normal offset, gives 2200 JST (10PM)
Notice a few things here. Firstly I'm using a 24 hour clock which goes from 0000 (00h 00m) which is midnight, or 12:00AM , to 2359 (23h 59m) which is 11:59PM. The reason being that it's much easier to work with a single number than a number and an AM/PM signifier. UTC is almost always represented in 24 hour format.
Secondly I did it in two steps, where you could do it in (kind of) one. Like: new time = time + (offset2 - offset1), or in this case new time = time + (9 - -7) or time + 16. This is of course the exact mathematical equivalent of what we just did, but without calculating the UTC time. However I'd encourage you to use the via-UTC method, as most of the time you'll want to know the UTC time anyway.
Thirdly, converting from Los Angeles time (PDT) to Tokyo time meant adding 16 hours. Is that the same as subtracting 6 hours? At 6PM in Los Angeles, then Tokyo is at 12PM, so are they not just 6 hours behind us? No, and this is very important, they are 16 hours ahead of us, which generally mean they are in the next day.
The International Dateline and the Sweeping Midnight Line
Assuming a straightforward 24 time zones, then for 23 out of every 24 hours there are two days on the planet. When investigating timestamps it's important to know which one of those two days the timestamp is in, especially if you convert from one timezone to another.
Everyone knows there's an International Dateline, and we've heard that you can gain or lose a day by traveling over it. But the dateline is of surprising little importance in date analysis. The more important thing is the Midnight Line.
The midnight line is the western edge of the time zone that's in the hour directly after midnight (i.e 0000 to 0059, or midnight to 1AM). To the west of the midnight line it's one day, and to the east it's the next day. Every hour the line jumps one time zone to the west. When the midnight line gets past Alaska to the international date line then for one hour all the time zones in the world are in the same day. Then an hour later the midnight line jumps over the international date line and it's 0000 (midnight, 12AM) on the next day in the first significant time zone at UTC+12 in New Zealand, which is why they get to celebrate the New Year first.
Unfortunately there's a kink in matters in that there's more than 24 time zones, and more than 24 possible times used in those. There's actually UTC+14 used by some pacific island. This means that they see the new day (and new year), a full hour ahead of New Zealand, who are actually on Daylight Savings Time at New Year, so are in UTC+13
And in the other direction (but about the same longitude), we have UTC-12, when the lowest offset should have been UTC-11 (the range is -11 to +12, which including 0 gives you 24 zones). Luckily UTC-12 is only technically used on a couple of uninhabited islands, so is unlikely to be an issue. But even with UTC-11 to UTC+14, that still means it's possible to have three calendar dates on the planet at the exact same time, which add an occasional complication to time zone conversions.
Here's a great overview of the history and complexity of odd time zones.
When do you add or subtract a day (or two) when converting times between zones?
You add a day if when adding an offset you go past midnight from one day to the next.
You subtract a day if when subtracting an offset you go past midnight from one day to the previous.
Pretty obvious really. And the reason the international dateline does not come into effect is that we are always doing our offset via UTC. Since the UTC line goes through London, and that's on the opposite side of the globe to the International Date Line, then we never cross the dateline, and the days all work out.
The only (very rare) complication might be at UTC+14. To go from UTC-11 to UTC+14, that's +25 hours. So if you are at 23:30 on a Sunday in American Samoa, then you pass the midnight line twice on your travel to 00:30 on a Tuesday on the Island of Kiribati (while it's Monday in most of the rest of the world.
How Time Zone confusion can introduce errors.
It's clear from the long description I had to give above that there's a lot of potential for errors to be introduced into a timestamp when converting time zones. The good news is that most of the internet timestamps are actually stored in UTC/GMT. The most common way of storing a timestamp is to use Unix Time, which is "simply" the number of seconds that have elapsed since 00:00:00 UTC on January 1 1970. Other than some ambiguity over leap seconds, this is essentially UTC.
The problem is that Unix Time is just a number of seconds, like 14335494425 (the time I typed that sentence). It's not human readable. The actual date it represents is 06/06/2015 00:10:25 UTC. The number has to be both converted into a readable time and date, and then displayed in the way the user expects, which is normally in their own time zone. So for me, I would want to see 17:10:25, or 5:10PM.
[To be continued]
Additional reading:
https://www.metabunk.org/how-to-find-the-exact-upload-time-of-a-facebook-photo.t4367/
https://www.metabunk.org/debunked-m...re-the-crash-and-other-timeline-issues.t3988/
Last edited:
