The calendar is overflowing the page now

Not on firefox though.

#welcome back 90's browser problems

Hmm, what to do? (fine in my Firefox too)
Images have max-width: 137px.
(137+10+1) * 7 + 1 = 1037 and the whole width is 1040. So 3 spare pixels according to my calculation!

It's caused by the text "https://forms.gle/TC5cAX5DKisqf1sL6" not being wrapped correctly on Chrome. I'll have a look if it can be solved somehow.

I've added: style="overflow-wrap: break-word" to the description text.
Does it help?

Quote from Scawen :

I've added: style="overflow-wrap: break-word" to the description text.
Does it help?

No it doesn't. I applied word-break: break-all; instead to that description text by using Chrome's Inspect Element. When I applied it to all of those texts that have that same URL in that description, it seems to work correctly.

The issue with word-break: break-all is that it applies a break between any two characters, even if the words are short enough to be wrapped on the next line as a whole. See the word "career" being broken up in two when I tested it:

I've solved the problem now by replacing words starting with 'http' or 'www.' with '[link]'

It's not actually a link but if they click it they will end up on the round's page so maybe this is OK at least for now. Though I realise they might write a link without any http or www.

Quote from Scawen :

A simple test is if someone could compare the in-game event browser with the website calendar and make sure it looks correct. Hovering over the event time should show the UTC time, in case that is useful.

Did a quick check on MRc FBM Saturday, I'm in UTC+1. All times I see are correctly 20:00 (that is: ingame, calendar view, round view), except the hover-over UTC text, which also says "20:00 UTC", instead of "19:00 UTC".

Oh, that is strange. It looks fine to me in Firefox if I go to UTC+1 timezone (the UTC hover text is an hour off from the visible text). I did have to refresh the page after changing time zone but then it looked correct.

It uses an html <time> element which in my browser shows local time normally but UTC time when hovering. It's the same with these forum post times (Today: 21:15) etc.

Hmm, strange. Here on forum it looks fine for me (visible "Today, 22:27", hover "Today, 21:27"), on calendar visible and hover text are the same. I wonder what's the difference between forum and calendar page. Here are the elements that are loaded on page for me:

- forum (correct):

- calendar (correct visible text, incorrect hover text):

Maybe your browser has a bug with data-format="time" ?

Instead of relying on that time tag I've now coded it manually instead, so I think it should work for you now.

I don't think the HTML <time> tag does any timezone conversion by itself, it's merely a semantic tag for marking a period in time and making it easy for machines to read it. There's probably some custom logic done for it in PHP or JavaScript.

It does seem correct now. (oh and I'm on Chrome 131)

This piece of JavaScript goes through all elements with a class name "DateField":


The issue is that the incorrect one had a class name of "DateField bold", which wasn't detected by that code.

Nice detective work there! I've reinstated the original code now without the "bold" and fixed the same issue in another few places.

It is still incorrect in the calendar. The text inside the <time> tag must be initialized with the UTC time, but in the calendar, it shows the converted time already even before the convert function is run. This is where it differs from the forum times for example - when I disable JavaScript, they show UTC times here.

OK, I've changed it to follow the convention.

But I don't see the harm in initialising with the already converted time, it seems to me that it just avoids a 1 frame glitch when you reload the page.

When initialising with the UTC text, it is at first visible at UTC then a split second later changes to the local time for the selected timezone.

EDIT: I've found that it still thinks I am in Thursday, even though I set my timezone to UTC + 1 and that is really Friday now... looking into it...

The content of the title tag is used as the tooltip text ("title" attribute):


If you wanted to do it as you wrote, the tooltip text would have to be taken from the "datetime" attribute and re-formatted correctly.

What function did you use to initialise it with the converted time?

I see... or I think I understand what you are saying but I still don't really understand why it worked fine on my computer.

For further confusion, and answering your question, I was able to manually adjust the time using a value called LFS::$session->vars['timeOffset'] which I understand to be a time zone offset.

But I'm not really sure what's happening now, as it seems sometimes that offset is set to zero, even though I have set a different time zone in Windows. It comes from a $_GET['t'] value at some point.

That offset being zero seems to be why my calendar still shows me in Thursday when my timezone is actually UTC+1 at the moment.

It looks like the JS code reads the value of an HTML element with an id "TimeOffsetOut" and sends in an AJAX request to PHP where it probably appears as the session variable. However I can't find such element with an id "TimeOffsetOut" in the output HTML.

Yeah I've been looking around, it's pretty hard to unpick as there are a lot of functions calling others and conditional interactions between javascript and php.

It's too complicated for me now as long past my bed time. Trying to figure out other people's code isn't my favourite task. Maybe I can unpick this stuff a bit tomorrow.

But can I ask one question, is that session variable correct for you? I mean... do you see the calendar on the correct day, i.e. moving into the next day as the "current day" before UTC is actually at that day? Just wondering if my offset is zero because that is sort of in my session already, so it's not "tricked" by me changing the Windows time zone.

It looked correct when I checked at around 0:45 my time (23:45 UTC) and it showed Friday as today in the calendar.

Thanks a lot for your help.

I guess it's worked out at some point then stored in the session variables.

So not really a bug, but it just doesn't deal well with windows changing time zone (even if I restart the browser).

I'm not sure if there's a better way to do it, or a more standard way to do it. Maybe the time offset is readily available in a php function so we don't really have to go through all this confusing code?

This one: https://www.php.net/manual/en/function.date.php, and this reference for the format string

edit: my data looks correct from here