Forum: Bug Report and Feature Requests

But the really strange thing I think is that the timestamp eventually corrects itself.

In that case Lazeez has an alien AI computer far ahead of what we have :D

Seriously, a difference of 60, 45, 30, or 15 minutes can be explained by timezoning. Either set wrong or the DST database is not up-to-date. As with all things MS thinks it can do better and uses its own database while there is an official IANA database which can cause minor differences.
The difference of a few 'rest' minutes can be explained by both sides not having set the time exactly the same (relative to UTC). DateTime is one of the trickiest things in programming, believe me, I know. Either way, a timestamp as used on SOL should always translate to the same date/time but just displayed according to your own culture settings.
(Date and time display settings are just a part of the culture settings, among others like language, number display settings, etc.)
(DST = Daylight Saving Time)

Well, I'm posting this comment at 13:20:40 UTC.

Edit: Which indicates the timestamp is 57 seconds behind my other sources. My other sources are:
- a radio-controlled clock
- this PC, which syncs via the Internet every few minutes.
- the SOL home page.

All three of those sources agree with each other to within a second. I'm assuming the SOL homepage does not simply pick up local time, there have been discrepancies in the past but something may have changed.

Well, I'm posting this comment at 13:20:40 UTC.

And I see a time stamp of

5/12/2021, 8:19:43 AM CDT.

Maybe the server clock is off a bit.

Maybe the server clock is off a bit.

Or your clock, or both ;)

Or your clock, or both ;)

No, my local clock setting shouldn't make a difference except at right around the transition points between CST and CDT. A given UTC value translated to my local timezone should give a fixed result without any reference to my local time.

No, my local clock setting shouldn't make a difference except at right around the transition points between CST and CDT. A given UTC value translated to my local timezone should give a fixed result without any reference to my local time.

From - Story Discussion and Feedback - Time zones

Lazeez Jiddan (Webmaster) 07/07/2018, 15:15:35

@Eldof

How does the time stamps on posted stories work? You know, where it says at the top of the posted chapter, something like Posted: June 23, 2018 - 08:15:37 am. The time stamp there, is that the authors local time zone, or are all stories here on SOL on a specific time zone? If so, which one? All I'm fairly sure of is that it's not the readers local time zone that's shown, since the story I'm following has all time stamps around 8 am while they show up for me on the afternoon or evening. Does anyone know?

It used to be (I just changed it) that the time stamp at the top of the chapters is in the server's time, which is Eastern. EST in winter and EDT in summer, so UTC -5 in summer and UTC -4 in winter.

I've changed it to work like the listings, so now it includes the code to show you the time stamp in your local time.

Replies: AmigaClone

From - Story Discussion and Feedback -Time zones

And nothing in that says or implies that the local clock value (current time, not the timezone setting) makes any difference, so I doesn't contradict what I said.

@Dinsdale posted:

Well, I'm posting this comment at 13:20:40 UTC.

You replied:

And I see a time stamp of 5/12/2021, 8:19:43 AM CDT.

Whilst to me, Dinsdale's post was at 12/05/2021, 14:19:43 & Updated: 12/05/2021, 14:26:47 both BST

What I see, what Dominions Son sees and what you see are entirely consistent. The server is running 57 seconds late. This message goes out at 14:29:00 utc, 15:29 BST.

What I see, what Dominions Son sees and what you see are entirely consistent. The server is running 57 seconds late. This message goes out at 14:29:00 utc, 15:29 BST.

I disagree.

Dinsdale (you) are working on UTC 13:20:40

DS is working on CDT 8:19:43

I'm working on BST 14:19:43

So. If the server is 57 seconds late, then that should be reflected in both your and my times as the server is working on CDT and we are not.

But in fact there is no 'lag' between CDT and BST, for which only the hours vary, as they should.

The 57 seconds difference shows between UTC and both CDT and BST.

I suggest therefore it's not the server that is 'late' it is your computer settings.

:)

I suggest therefore it's not the server that is 'late' it is your computer settings.

And what exactly are you suggesting is the issues in the settings.

It can't be the local system clock time value. The only impact that would have is whether my system is using CDT or CST as the local timezone. That transition happens only twice a year and we are currently no where near either transition point.

I suggest therefore it's not the server that is 'late' it is your computer settings.

You are joking? Please?
I hit "Transmit" when my computer's clock showed 13:20:40. The posting showed up as having been created at hh:19:43 where hh was timezone-dependent.
My radio-controlled clock shows the same time - to the second - as my PC, and as SOL does on the home page.

It was a similar story with the posting you just replied to. I entered the timestamp where I was going to make the post, waited until that time came up and hit transmit.
You should maybe try something similar.

You are joking? Please?
I hit "Transmit" when my computer's clock showed 13:20:40. The posting showed up as having been created at hh:19:43 where hh was timezone-dependent.
My radio-controlled clock shows the same time - to the second - as my PC, and as SOL does on the home page.

It was a similar story with the posting you just replied to. I entered the timestamp where I was going to make the post, waited until that time came up and hit transmit.
You should maybe try something similar.

You are looking at the time stamp incorrectly. You can't place the time that is shown on your clocks as an absolute plus or minus the time zone. An easy way to see this is to have a clock or watch that will not adjust to cell towers or GPS then just drive 50-100 miles and watch how your cell phone clock will adjust and change times to how the area you are now in believes how the time should be compared to what the time is showing on your control clock at the start of your journey.

The point is that no matter what you see as a time on your devices is meaning less as that the server time is set by location and the way it is synched and the only way your time will match with the server is if it is in the same area and synching the same way as the server.

If I go to this website

https://time.is/Monroe,_Michigan

there is a 14 sec difference between the time shown on the website and the time that my cell phone shows which is controlled by the cell towers I connect to in my area.

Initially the world was divided into 24 standard time zones which extend from the South Pole to the North Pole. However, due to different geographical, social, and political reasons according to the list of world time zones which is based on IANA (Internet Assigned Numbers Authority) the time zone database shows there are about 200 time zones in the world.

Listing of time zones :

https://24timezones.com/time-zones

You are making some strange assumptions, and some of your syntax either confused or confusing.

An easy way to see this is to have a clock or watch that will not adjust to cell towers or GPS then just drive 50-100 miles and watch how your cell phone clock will adjust and change times to how the area you are now in believes how the time should be compared to what the time is showing on your control clock at the start of your journey.

wtf?

ok, no cell phones involved.
I'm in a fixed location, my computer gets its time from a pool of ntp servers and modifies the values to fit the timezone I have specified.
The values I get are within a second of the times the SOL main page shows me, the timestamps the comment server shows should agree with the main page, they don't.
I also have a radio-controlled clock, as it happens the server is also in this city. The times match my PC - and the SOL main server - to within a second.

I looked at your Munroe Michigan link. The mm:ss time it gives me is around half a second away from my computer's time, along with the expected deviation in hours.

The server which handles Forum posts is running almost a minute slow. This happened with the main page a few years ago - before Lazeez started using ntp servers - although I remember the offset as only having been a few seconds.

The server which handles Forum posts is running almost a minute slow.

...or, it could be that Lazeez is subtracting a minute from the time to (over?)compensate for the delays in posting - after all, if you've just submitted a post, chances are that a minute ago you were still typing it.

A ridiculous idea.
And when I say "this posting submitted at hh:mm:ss", what I actually do is enter a time a few seconds in the future, wait for the time to come around and . . Post.
I'll be sending this one at 07:43:30 utc.

when I say "this posting submitted at hh:mm:ss", what I actually do is enter a time a few seconds in the future, wait for the time to come around and . . Post.

That's what I understood and expected you to be doing

I'll be sending this one at 07:43:30 utc.

...and the TS showing for me is

13/05/2021, 08:42:32 (BST), which 07:42:32 UTC; looks like plus a couple of seconds for the network and processing delays, and minus a minute for some purpose not disclosed.

A ridiculous idea.

If it walks like a duck, looks like a duck, and sounds like a duck, then you'd have to be quackers to deny it might be a duck

However, getting back to the OP complaint, if you select the timestamp and view the underlying code (double-click+drag, right click, View Selection Source in Firefox) you will see (on your post which this is a reply to, spaced to avoid code issues)

< i class="timestamp fr">< script>tstamp = new Date(1620891752000);document.write(tstamp.toLocaleString());< /script>13/05/2021, 08:42:32< noscript>2021-05-13 3:05:32am< /noscript>< /i>

You'll have your own chosen format for the 13/05/2021, 08:42:32 bit between < /script> and < noscript>, but notice the < noscript> bit: 2021-05-13 3:05:32am, some 22 minute (and N hours) different - I think THIS is what was originally observed, and the OP for some reason didn't have javascript enabled initially (possibly due to browser background actions).

I'll be hitting the [post] button at 08:40:00 GMT/Z/UTC (09:40:00 BST) so expect a timestamp a couple of seconds later.

ETA: and the timestamp came up as 13/05/2021, 09:39:02 BST on refresh, which is BEFORE I hit the [post] button, so there's a rabbit away somewhere - that quacking's getting louder.

You'll have your own chosen format for the 13/05/2021, 08:42:32 bit between < /script> and < noscript>, but notice the < noscript> bit: 2021-05-13 3:05:32am, some 22 minute (and N hours) different

The source and resulting format is a bit confusing.
The date/time between the script and noscript tags shouldn't be needed as with Javascript enabled only the script part will display and without Javascript only the noscript part.
The timestamp 1620891752000 translates to May 13, 2021 7:42:32 AM UTC, so the time between script and noscript is probably timezone adjusted, which the tstamp.toLocalString() should already have done. This makes me wonder why we don't see a double display.

the time between script and noscript is probably timezone adjusted, which the tstamp.toLocalString() should already have done.

Yes, but remember what I pasted was not the source, but copied from the browser window so comes from after the script processing; when the javascript is run, that bit gets changed (filled in by the code) so you'll only see one copy, the result of the latest code execution. In the html sent, that bit is empty, you can verify this by capturing the raw html sent from the site with something like wget or a download manager, so the code execution just fills in the readable timedate. My point regarding the code is that the string that's displayed if the code is not run gives a time that's 22-odd minutes (and whatever hours) different from reality, and is likely the source of the original observation - and probably that there's some server time that Lazeez has missed in checking the synchronisation (or borked code for time adjustment) for the noscript time. My quacking about the back-a-minute post time is separate from the code issues, and still stands. ETA: ...and is totally unimportant, except to nerdy pedants like me.

Yes, but remember what I pasted was not the source, but copied from the browser window so comes from after the script processing; when the javascript is run, that bit gets changed (filled in by the code) so you'll only see one copy, the result of the latest code execution.

Still strange. Look at one of the ReaderInfo contributor pages where similar code is used. Just script and noscript tags in the source and only one of them displays depending on Javascript enabled or not.

My point regarding the code is that the string that's displayed if the code is not run gives a time that's 22-odd minutes (and whatever hours) different from reality, and is likely the source of the original observation - and probably that there's some server time that Lazeez has missed in checking the synchronisation (or borked code for time adjustment) for the noscript time.

The noscript part is a fixed date (not changed by Javascript) but is probably generated by PHP code. Since PHP runs server side the source of the discrepancy comes from the server. Probably the different ways of handling the timestamp conversion between Javascript and PHP.

...and is totally unimportant, except to nerdy pedants like me.

Yep, I'm afraid I'm also one of those :D

My point was that you are saying that because all your time devices say the same exact time that everything must then match the same exact time as you with exception for the hour of the time zone and this just isn't always true. Lazeez just said he synced the servers' clock and that it was off by few seconds I bet in a couple of months we will start see the time drift again. Not everything syncs exactly the same or to the exact same time and that is why we have clocks syncing but even then it isn't exact. If and atomic clock experience an error of 1 second every one-hundred million years or so what is the error on lower machines like computers and watches.

It's rather technical, but try looking at Network Time Protocol, and know that Unix machines running NTP synchronise every few minutes. Network delays mean that accuracy is maybe down to 0.5 seconds, although that applies less with servers such as those SOL runs on. Machines running Windows synchronise less often, but I don't know how far that goes - it may be configurable with some versions.
Not all time zones are a fixed number of hours from UTC. Most are, but "Newfie time" is 30 minutes off US Eastern and some countries / areas use 15 minute granularity - see https://www.timeanddate.com/time/zone/australia for instance.

Time zones also change for various reasons.
I believe Saudi Arabia used "Sun Time" until pretty recently, head a few miles E or W and the time zone would change by a few seconds. Your previous posting seemed to imply you thought that applied where you are.

Three soldiers marching, A, B & C.

A is out of step, B & C are in step with each other.

B states that since B and C are in step, A is out of step.

A states that the fault lies with C

Who is correct?

Who gives a f*** what three mythical soldiers think?

I have three independent time sources here, they agree to within a second.

If one of them diverges - and I notice - I start trying to work out why. All three have had their problems in the past.

- My PC's time started drifting when the time server I was syncing to went offline. I now use a pool.

- The SOL main page has drifted in the past, possibly for similar reasons.

- My radio-controlled clock was in a place where the control-signal was blocked. I moved it. I actually have two of them in different rooms but one only shows hh:mm and I only actively check that one twice a year, you should be able to guess when.

My previous posting appeared to be 58 seconds out so here's another timestamp for control purposes: 08:00:30.

Edit: yes, drift is increasing. I thought Lazeez monitored the Forum but maybe he was meditating earlier.

Who gives a f*** what three mythical soldiers think?

Obviously not you.

Oh, and the mother watching a march past who shouted out. "Oh look, my son is the only one in step."

:)

You replied:

And I specifically noted that the slight difference in the hours/minutes/seconds of the time stamp and what Dinsdale self reported is probably the result of the server system clock being slightly off.

I see what you mean - another server, another discrepancy. I have the discrepancy at 6:40:00 and will contact our heroic webmaster, he seems to have another server to sync.

A given UTC value translated to my local timezone should give a fixed result without any reference to my local time.

That's not exactly how it works. The result from UTC to your local displayed date and time is reached by using the timezone in your culture settings as an offset to the UTC time. With changing DST this results in a different offset. If you are in a zone without DST changes, the same UTC should always display as the same date/time following your culture settings, i.e. the fixed result you mentioned. Since your clock setting is part of the calculation that does make a difference.

Since your clock setting is part of the calculation that does make a difference.

True, but not particularly relevant, because the specific clock setting will only make a difference around the transition points between CST and CDT (the transition happens at a specific time of day), which I specifically mentioned up thread.

We are months away from both the last transition and the next transition.

As it should be. My times are correct too. It was about the differences Mat encountered.

58 seconds. Tomorrow it will be around 59 unless something changes.

Edit: Oh, and that only applies to the timestamps for the postings. The timestamp on the line below
Forum: whatever
is correct, the timestamps after the Last updated: text match those on the posts themselves - currently 58 seconds off.

I believe the time to be 21:32:00 utc at the time of posting this message.

Edit: Yes!