Freezing Saddles 2015 ~ At Least Yer Not in Kiev, Comrade

[Subby]

The only weird thing I see is one rider has 4 days in the books after only three days.

Sent from my iPhone using Tapatalk

[TwoWheelsDC]

@Subby 103458 wrote:

The only weird thing I see is one rider has 4 days in the books after only three days.

Sent from my iPhone using Tapatalk

For Will, it makes sense…not sure why the other guy has 4 days though.

[hozn]

I will check the data. I thought I cleared out everything and updated the configured start date .. Will let you know what I find.

[peterw_diy]

it is Jan 4 now… UTC.

[hozn]

@peterw_diy 103461 wrote:

it is Jan 4 now… UTC.

Yeah, that is the crux of the problem. (Time zone.) I specified “2015-01-01” as the start date, but I think that was evaluated as UTC. Hence a few rides from Jan 31 (post 7pm) were included when the strava data was synchronized. I have made the start time explicit as UTC-5, since as far as I know the competition starts at Jan 1 *our time*. The role of time zones around competition boundaries may merit further discussion.

[peterw_diy]

@hozn 103463 wrote:

Yeah, that is the crux of the problem. (Time zone.) I specified “2015-01-01” as the start date, but I think that was evaluated as UTC. Hence a few rides from Jan 31 (post 7pm) were included when the strava data was synchronized. I have made the start time explicit as UTC-5, since as far as I know the competition starts at Jan 1 *our time*. The role of time zones around competition boundaries may merit further discussion.

+1 on contest times being US/Eastern.

To get this right, bafs should do real date math if Strava speaks UTC — we Spring Forward 11 days before this ends, so hard coding -5h isn’t always right.

[jrenaut]

As someone who writes software for a living, the fact that we still can’t figure out how to handle f’ing dates consistently makes me really sad. I mean, it’s going to be a s**tshow as we approach midnight on December 31st, 9999 and a godlike AI that hosts tens of millions of uploaded minds realizes that it can’t handle a 5 digit year.

[TwoWheelsDC]

@jrenaut 103477 wrote:

As someone who writes software for a living, the fact that we still can’t figure out how to handle f’ing dates consistently makes me really sad. I mean, it’s going to be a s**tshow as we approach midnight on December 31st, 9999 and a godlike AI that hosts tens of millions of uploaded minds realizes that it can’t handle a 5 digit year.

Stardates are 5 digits, so your fears clearly are unfounded.

[jrenaut]

@TwoWheelsDC 103479 wrote:

Stardates are 5 digits, so your fears clearly are unfounded.

It might be 99,999 then. But you’re crazy if you think we won’t have another panic equivalent to the Y2K crap. And the next one will be worse because we’ll be even more dependent on computers for everything. It’ll probably be Microsoft’s fault.

[peterw_diy]

5 digit years, bah. We’re less than 25 years away from 32bit time_t overflows.

I wish we’d ditch the freaking DST stuff. Ridiculous all the stupid places tzdata is stored…

[jrenaut]

What we really need to do is just count seconds since 1/1/00 GMT and then localize from there. Anyone caught storing a date in any other format has to spend a month using only AOL dial-up.

[hozn]

@peterw_diy 103465 wrote:

+1 on contest times being US/Eastern.

To get this right, bafs should do real date math if Strava speaks UTC — we Spring Forward 11 days before this ends, so hard coding -5h isn’t always right.

Yeah, don’t worry; the end time is specified as -0400.

Yeah, the application code is timezone aware; however, strava doesn’t always use utc — activities have both utc and local stamps and we prefer those local times so that it doesn’t show vvil’s sunny ride as midnight. The bigger issue here is that mysql doesn’t support timezone date/times. It is a horrid database, but that’s what the shared hosting account provides. We could cast everything to UTC in db and them convert back to the tz of the activity … but right now it is simple enough still to just store the local times for rides and only consider tz for the boundary dates.

[hozn]

@peterw_diy 103482 wrote:

5 digit years, bah. We’re less than 25 years away from 32bit time_t overflows.

Yeah, this is an awesome little y2k time bomb. I can’t wait!

[peterw_diy]

@hozn 103486 wrote:

strava doesn’t always use utc — activities have both utc and local stamps and we prefer those local times so that it doesn’t show vvil’s sunny ride as midnight. The bigger issue here is that mysql doesn’t support timezone date/times. It is a horrid database, but that’s what the shared hosting account provides. We could cast everything to UTC in db and them convert back to the tz of the activity …

Well, it’s not like it’d be all that tough to store the tz offset in a separate column and create a view with UTC, Eastern, and Original Local time columns. But too bad that’s not just included – though IMO MySQL does pretty well for $0 (vs $4k for Microsoft or $30k for Oracle). Too bad bafs cares about both local and absolute time.

[hozn]

Yes, it would not be too hard, just not insignificant work and hasn’t proven necessary yet.

MySQL is fine of you don’t care about data integrity or SQL standards. It is easy to setup/”administer” which is what I assume has made it successful. It pairs nicely with PHP, which I think sums up its applicability. No, I have little admiratiom for MySQL when there are (and have been forever) enterprise-grade databases like Postgres that also costs $0, has a less restrictive license, and is a less dysfunctional OSS project (i.e. not owned by Oracle).

[Author]

Posts