[monist]

Just looked at my most recent tourney result. Stated time of the game had not even arrived in my timezone. Here's an easy solution I use on my site:

) Server sends all DateTimeStamps as Unix epoch time
) Browser JS client converts to local time where user is located
) added bonus: epoch time is very compact

Here's an example function for the client side, which is simple and readable, but could easily be made to contain more detail:


const get_DayHourMin = (epoch_secs) => { // example of return val: Thu 1:45p

const date_str = `${new Date(epoch_secs * 1000)}`

const timestamp_ary = date_str.match(/^(\w{3}).+(\d\d)\d\d):\d\d/)

const day = timestamp_ary[1]

let hour = Number(timestamp_ary[2])

let min = timestamp_ary[3]

if (hour > 12) { // make 24hr time 12hr time

hour -= 12
min += "p" // p.m.
}
else { min += "a" } // a.m.

return `${day} ${hour}:${min}`
}

In general, I think y'all's site is amazing, and I play way to much online bridge. I've borrowed a bunch of ideas from you for my site word game site -- https://lexluv.com -- especially the concept of a new user session causing the previous client to shut down. BTW, you should also investigate push notifications...

Cheers!

[barmar]

This is the first I've heard anyone report a problem. The way it currently works is that the browser sends its timezone offset to the server, and the server adjusts all times by this offset.

You're talking about myhands, right?

[pescetom]

barmar, on 2024-April-11, 09:34, said:

This is the first I've heard anyone report a problem. The way it currently works is that the browser sends its timezone offset to the server, and the server adjusts all times by this offset.

You're talking about myhands, right?

Even History gets the timestamp wrong, not that it bothers me much.
I just played a tourney starting at 9pm CET and in History it shows as 14:01.

[0 carbon]

I get different results with different browsers at https://webutil.brid...lobalClub&md=10

I've had to use Spoof Timezone addin.

[barmar]

Tourname times in History are shown in BBO's server time, which is US Central Time. I'm not sure why we don't translate it to local time, but it's been llike this for ages.

Times in myhands are converted to local time.

[pescetom]

barmar, on 2024-April-15, 14:07, said:

Tourname times in History are shown in BBO's server time, which is US Central Time. I'm not sure why we don't translate it to local time, but it's been llike this for ages.

Times in myhands are converted to local time.

It would make sense to translate history to local time too.
Not that it's in the top 100 on my own list of to do eventually, or that I have great hopes for the top 20

[0 carbon]

pescetom, on 2024-April-15, 14:37, said:

It would make sense to translate history to local time too.
Not that it's in the top 100 on my own list of to do eventually, or that I have great hopes for the top 20

With daylight savings time, I can see some complexities calculating what time to display for every hand/tourney in the past.

Suggestion: BBO should start using UTC - no DST to worry about, no time zones. The military uses if for the same reason - they call it Zulu time, eg, 1901z

[barmar]

0 carbon, on 2024-April-21, 11:57, said:

With daylight savings time, I can see some complexities calculating what time to display for every hand/tourney in the past.

Suggestion: BBO should start using UTC - no DST to worry about, no time zones. The military uses if for the same reason - they call it Zulu time, eg, 1901z

Most humans don't understand UTC, this would hardly be an improvement.

[pescetom]

barmar, on 2024-April-22, 14:21, said:

Most humans don't understand UTC, this would hardly be an improvement.

I understand (or at least have learned) that you prefer to play bridge rather than improve BBO, but surely the suggestion was entirely sensible: UTC would be translated into their current timezone with no error of DST, assuming BBO had the minimal energy to explain to its own software that the basis was no longer US central time but UTC

[smerriman]

pescetom, on 2024-April-22, 15:29, said:

but surely the suggestion was entirely sensible: UTC would be translated into their current timezone with no error of DST

I can't see anything remotely sensible about the suggestion, so we must be understanding it differently. 0 carbon was suggesting the History tab shows times in UTC with no 'translation in the current timezone' at all. This would mean the time shown would be "wrong" for virtually every user.. local would obviously be better (though I'm well aware that it is not as trivial as it sounds), but the current setup of BBO time is at least understandable.

[mycroft]

Browsers can calculate time from anywhere.

Displaying UTC is unhelpful for most humans, so I'm assuming you're going to have everything add javascript to "home it" for the user. Which puts us back where we were.

I do realize that UTC is much better understood when in UK time or UTC+1/+2, but for the majority of NA, the numbers are difficult enough to autocorrect even if we do know what our "number" is.

Of course, since I'm now 90+% UTC-6 (Mountain Daylight Time or Central Standard Time) it doesn't much matter (but I did have to look up to confirm that yes, it is UTC-6. I do time conversions all the time for my job, and still aren't 100% sure what time it is here relative to UTC).

[pescetom]

0 carbon, on 2024-April-21, 11:57, said:

With daylight savings time, I can see some complexities calculating what time to display for every hand/tourney in the past.

Suggestion: BBO should start using UTC - no DST to worry about, no time zones. The military uses if for the same reason - they call it Zulu time, eg, 1901z

smerriman, on 2024-April-22, 16:35, said:

I can't see anything remotely sensible about the suggestion, so we must be understanding it differently. 0 carbon was suggesting the History tab shows times in UTC with no 'translation in the current timezone' at all. This would mean the time shown would be "wrong" for virtually every user.. local would obviously be better (though I'm well aware that it is not as trivial as it sounds), but the current setup of BBO time is at least understandable.

As I read his quote above in the context of the discussion, he was suggesting that while they fix the issue of only translating times in Hands but not in History, they could also migrate from DST to UTC as a base to avoid the "daylight savings time" issue as well.
In any case, not on my top 100 problems list

[pescetom]

mycroft, on 2024-April-22, 16:46, said:

I do realize that UTC is much better understood when in UK time or UTC+1/+2, but for the majority of NA, the numbers are difficult enough to autocorrect even if we do know what our "number" is.

Of course, since I'm now 90+% UTC-6 (Mountain Daylight Time or Central Standard Time) it doesn't much matter (but I did have to look up to confirm that yes, it is UTC-6. I do time conversions all the time for my job, and still aren't 100% sure what time it is here given UTC).

As you say UTC is better understood in Europe however (where BBO's programmers are) and from where the DST/EST issue need some looking up too

[0 carbon]

My problem is that hand archives times are 4 hours late in LibreWolf & Opera browsers in https://webutil.brid...obalClub&md=100 - UTC?

Times are usually correct in Firefox, Vivaldi, Iron, Brave, Waterfox, Edge, Chromium, Chrome (except over a DST change). The page uses Javascript.to set the times.

My argument for Zulu time in hand archives is to avoid complexity, timezone & browser incongruities, and incorrect times for archives spanning a DST change



FWIW, TIL that Windows uses the local time zone for file dates/times (& probably much else), while Linux & Android (& probably Unix & MacOS & IOS) use UTC, then converted to the local timezone for display. This means that windows files transferred across time zones do not have the right times for the destinations.

[0 carbon]

The big advantage of UTC over local time is that you can coordinate with partners all over the world without timezone gymnastics, complicated by DST.
Far from only a few seeing it as their local time, everyone can see it as their BBO time.
Or.... https://en.wikipedia...h_Internet_Time "During 1999, Swatch produced several models of watch, branded "Swatch .beat", that displayed Swatch Internet Time as well as standard time, and even convinced a few websites (such as CNN.com) to use the new format. PHP's date() function has a format specifier, 'B', which returns the Swatch Internet Time notation for a given time stamp. It is also used as a time reference on ICQ, and the online role-playing game Phantasy Star Online used it since its launch on the Dreamcast in 2000 to try to facilitate cross-continent gaming (as the game allowed Japanese, American and European players to mingle on the same servers)."

[barmar]

0 carbon, on 2024-May-06, 17:38, said:

The big advantage of UTC over local time is that you can coordinate with partners all over the world without timezone gymnastics, complicated by DST.

I think you give people too much credit to be able to understand this. I suggest you try asking a bunch of random Americans what their offset is from UTC, I'll bet fewer than 10% know it.

In the course of my 4-decade career, I've worked in several organizations that had multiple offices around the country or world. Yet none of them have standardized on UTC as the time reference. Usually there were just two offices, so we said times in both timezones. When I worked for a group that was split between Cambridge and Phoenix, we got used to the fact that the time difference switched between 3 hours and 2 hours every 6 months, because AZ doesn't use Daylight Saving Time.

BBO employees are all over the world (until we merged with FunBridge, it was entirely work-from-home). For historical reasons, most of the servers use US Central Time, so that's the time in all the log files and the developers have gotten used to it as our base. Now that we're a subsidiary of a French company, management tends to use CET when announcing meeting times.

[pescetom]

barmar, on 2024-May-15, 11:52, said:

I think you give people too much credit to be able to understand this. I suggest you try asking a bunch of random Americans what their offset is from UTC, I'll bet fewer than 10% know it.

In the course of my 4-decade career, I've worked in several organizations that had multiple offices around the country or world. Yet none of them have standardized on UTC as the time reference. Usually there were just two offices, so we said times in both timezones. When I worked for a group that was split between Cambridge and Phoenix, we got used to the fact that the time difference switched between 3 hours and 2 hours every 6 months, because AZ doesn't use Daylight Saving Time.

BBO employees are all over the world (until we merged with FunBridge, it was entirely work-from-home). For historical reasons, most of the servers use US Central Time, so that's the time in all the log files and the developers have gotten used to it as our base. Now that we're a subsidiary of a French company, management tends to use CET when announcing meeting times.

BBO users are from all over the world too, even historically
In case it was hard to guess, the rest of the world has no idea about their offset from US Central Time, let alone what and when you do about Daylight Saving.

Not that this is a real issue, agreed, but UTC mapped to local time seems an ideal solution.