Subtle changes, bugs and feedback

Nothing has changed.

I have added no code that says "screw with DJ, sent him back to old posts".

Serves you right for not reading them properly the first time around. :)

You saying the code was there before? ;)

I came here to say how I liked how the java time stamps worked combined with browsers that cache.

First post in following, said "replied 3 hours ago". I guess I better refresh then.

Dates on events now work across timezone boundaries.

So if you are in Portland and create an event for 11pm, and then access the site from London, it will show correctly as being at 6am, and if edited from France and then you fly back to Portland, the time will show 11pm there as expected.

Basically... we store UTC, and we return HTML containing UTC, but the display and forms use JavaScript to take the local browser setting, so that it always show the time according to whatever your browser locale is.

I'd prefer sidereal time if it's not too much bother.

The front-end is open-source and on Github, submit a pull request with the relevant changes.

Proposal:
When editing, if a location is chosen, treat the time input as location-local. Ignore browser locale.
When displaying, if the location is in the same timezone as browser locale, show local time, otherwise show both location-zoned time and browser-locale-zoned time.

Velocio, thanks for your time and effort. I am not actually affected by these changes at all, my posts and threads were. I don't take any of it personally. My interaction is vastly reduced here, as there were some things I didn't like here before. That said, the forum is a great community. The photography and horology threads in particular are quite special.

Just noticed a lot of the pre-move youtube embeds in covers thread are now broken
https://www.lfgss.com/conversations/172167/?offset=450

Oddly some of the older ones have an embed and the now broken BBCode

If you have a database that maps lat:lon to timezones and keeps them up to date across daylight savings, and applies to the whole world... then sell it, because no-one else has a truly accurate database like this. The best timezone one is within the Linux world, but isn't coupled with a full lat:lon database, just city relationships to timezones.

Device clocks are actually a damn good guide, all mobile devices update their clock from the network when crossing borders nowadays, and people who travel that much do change their laptop clock as you're usually doing meetings and researching local time-based stuff.

So it works, and it works well.

There is a catch though... with what I've done. Whilst it's very natural and involves no config, it doesn't know about changes to daylight savings.

So if you create an event that is on Monday 27th October, and it's presently Saturday 25th October, and you created it to start at noon, it would be saved as 11am UTC. After the clock changes on the 26th October it would display as 11am GMT.

This is technically correct as the UTC representation didn't change... but it's obviously flawed as it should know that the event date on the 27th was noon GMT and should be saved as noon UTC.

The problem I have is that if I fix that (and I could with some effort... an API call to a time database asking what the time will be on some specified date within a specific timezone - no location info though)... then the event would save showing the time as 1pm BST, and the vast majority of people creating and editing events would consider that to be a bug. They think simple and just want to say "Noon" and we'd change it to 1pm BST/Noon GMT and they'd freak out and change it back. And I could show the time twice, but this would greatly confuse them.

Basically an edge-case is the clock changes, but I have no elegant solution that people would not treat as a bug either way.

Well if you don't mind I may take some time and clean up some of the others too. Though I think I'll have to do it fully manually as clearly relying on regular expressions to do most of the work and then my just re-phrasing the occasional bit manually isn't working.

Good catch, I had run a script (originally supplied by the vBulletin hack that did the embedding) to find all of those but it's obviously missed a fair few.

I'll go and look at how many there are and how to fix it.

Fixed, some 22,457 comments were affected, and all should be working now. I just need to purge the cache to have the results display.

Is it a new feature that when you click to load a single comment, it shows the whole thread of related comments? Or have I just missed this.

I wonder if this might be a better way of doing 'in reply to', to show those in a new tab (not a new tab because there was some chat about that not being standard behaviour?)?

Anyway, its great :)

That's been there since the launch. It provides a way to permalink a comment and to see what is in reply to as well as the replies to it.

Ha. I've definitely looked at single comments since then. Obviously not any conversations though #fail

If anyone's wondering what the intermittent slowness/breakage is, http://status.linode.com/incidents/c5f717108szl (our hosting provider)

lines starting with a 'greater than' denote quoted text

Shouldn't the "cannot be empty" thing for posts stop that^

No, because we don't have proper quoting any more, so-called "quotes" are just blocks of text like any other.

I shall try and be helpful. This might not work for you, but I used to solve those sorts of problems for Bookatable, so this might help.

Storing date times as UTC (or milliseconds since epoch) is absolutely the right approach. Trying to store and calculate time zone and DST offsets on a server is a descent into madness. Keep the server in a known state and treat the client as accurate.
If the user created the event for a time after DST ends but creates it while DST is in place, well it doesn't matter. Have the client send a datetime as milliseconds since epoch or as UTC. and it ought to be accurate for the event. If you do need the Timezoneoffset offset then JS can send it. If you need to know whether DST is in play then you can compare it with a new date at the same time, but the month set to January, which won't be DST anywhere. If there's an hour's difference it's DST.
This ought to be enough to render it on the client with the correct date and time for the event on the server, but for extra peace of mind send it to the client in UTC or epoch and use JS to display it in the user's local time. It should be accurate then, no matter what.

That is what I have done.

Client sends UTC to server, that's what we save.
We send UTC to client, and client renders local time.

The only additional thing I could do is to ask the user at the time of creating the event which timezone the event occurs within. Namely, to ask which IANA Time Zone location ( http://www.iana.org/time-zones ) i.e. America/New_York , that the event occurs within. This would allow me to determine precisely when DST starts/ends (if it applies at all) and would allow me to represent the correct date and time even through the DST changes.

I can't use an event lat:lon to do a nearest city, as a border location may return the wrong location.

And the big concern I have with this is that only *nix systems have this deep knowledge of timezones, and so whilst we are prepping to open source the code base we would have introduced the first thing that made it system specific.

I also note that Google Maps API includes a lat:lon overlay to the IANA Time Zone database ( https://developers.google.com/maps/documentation/timezone/ ), so that might be possible too. That looks like a good answer, but I still have the issue of whether I display the adjusted time stamp pre-DST for an event post-DST and vice versa... not doing so is more intuitive but incorrect, and doing so is correct but unintuitive.

I'm basically settling for leaving this and figuring out how much of a problem the edge case is later.

This shouldn't be a problem then.

So if you create an event that is on Monday 27th October, and it's presently Saturday 25th October, and you created it to start at noon, it would be saved as 11am UTC. After the clock changes on the 26th October it would display as 11am GMT.

The JS should give you the right UTC for the event date and time, not the current date and time and vice versa.

It does.

But if you create an event on the Saturday 25th October for 10pm in London, the UTC is 9pm.
If you view the event on Monday 27th October the UTC is still 9pm and as no DST now applies the local event time will be shown as 9pm.

My point is that someone intended it to be 10pm, and it now says 9pm. I've stored the right value given their input, but it's the wrong value given their intent (the event is at 10pm, which is what they chose in the drop-downs, they meant to store 10pm UTC).

And if I made sense of this, it would mean showing 11pm BST on Saturday 25th, so that 10pm GMT was the event time... but most users would regard that as a bug... users don't think of DST.

And we're not the only one that struggles with this, even Google Calendar has these issues to some extent: https://support.google.com/calendar/answer/2367918?hl=en

The only edge case is about events that span daylight savings changes, and in our scenario as we're using a simplified version events created/editing within one DST and that occur within another.