Interpretation of Months & Days - 31 day months vs. variable length months.

[connorsb]

Connor from OpenPittsburgh & the pabudgetclock here - I noticed this today while messing about with the PA clock.

It's Feb 1, and our clocks both start from ~July 1, so we're at exactly 7 months, 0 days.

But that's not how the two clocks read - they're off by 4 days.

This is because the subtraction math produces a duration and the duration treats all months as being 31 days, so there's some skew between the real month-length and the "ideal 31 day month" month-length, as we've had a few months of 30 days interspersed.

It's not wrong, it's just a different conception from how I'm guessing the layman might interpret months.

If we all wanted to switch to a different conception of how count the time-differences, I'd suggest using http://momentjs.com/docs/#/displaying/as-object/ as an OK starting point.

Pull both this moment and the start-time as objects, and then do some subtraction to get the Months, Days, Hours, etc.

That's maybe beyond my current skill level to do quickly, but maybe yinz team has some serious moment.js hackers?

(also, yes, our two clocks are off by a few hours. They should be off by exactly one (Central vs. Eastern time). Not sure why.)

[derekeder]

@connorsb thanks for looking into this! I'll spend some time on this tonight and see what I can do.

For the hour differences, i think it has to do with the starting hours. Also, timezones are hard.

• IL: July 1 2015 5:00:00
• PA: June 30 2015 23:00:00

Moment does have a timezones library, which seems like overkill to me, but one issue is the clock is in client-side javascript so it will show the countdown based on the user's timezone.

[connorsb]

@derekeder If the two clock's "start time" has a hardcoded timezone, that should be all we'd need to mess with in terms of timezones. Moment takes care of conversion to the user's local timezone on its own.

[derekeder]

I think this is resolved.