Closed notthetup closed 10 years ago
My beef with ISO 8601:
The issue with the RFC3339 is it doesn't explicitly state the format. At least we couldn't find it.
All I found was
"The following profile of ISO 8601 [ISO8601] dates SHOULD be used in
new protocols on the Internet. This is specified using the syntax
description notation defined in [ABNF]."
OK. Found it. Although very clumsily expressed.
date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
; month/year
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second
; rules
time-secfrac = "." 1*DIGIT
time-numoffset = ("+" / "-") time-hour ":" time-minute
time-offset = "Z" / time-numoffset
partial-time = time-hour ":" time-minute ":" time-second
[time-secfrac]
full-date = date-fullyear "-" date-month "-" date-mday
full-time = partial-time time-offset
date-time = full-date "T" full-time
http://en.m.wikipedia.org/wiki/Backus–Naur_Form
On Thursday, August 28, 2014, Chinmay Pendharkar notifications@github.com wrote:
OK. Found it. Although very clumsily put.
date-fullyear = 4DIGIT date-month = 2DIGIT ; 01-12 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on ; month/year time-hour = 2DIGIT ; 00-23 time-minute = 2DIGIT ; 00-59 time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second ; rules time-secfrac = "." 1*DIGIT time-numoffset = ("+" / "-") time-hour ":" time-minute time-offset = "Z" / time-numoffset
partial-time = time-hour ":" time-minute ":" time-second [time-secfrac] full-date = date-fullyear "-" date-month "-" date-mday full-time = partial-time time-offset
date-time = full-date "T" full-time
— Reply to this email directly or view it on GitHub https://github.com/webuildsg/webuild/issues/58#issuecomment-53660052.
Side note: This will be a major version upgrade with respect to semantic versioning.
MAJOR version when you make incompatible API changes
You could add a new property with the RFC3339 format, keep supplying the old property too, and retain backwards compatibility. (Sounds ugly but in many real world environments, where you have old un-updatable clients in the wild, that may be the only acceptable solution.)
On Wed, Sep 3, 2014 at 9:22 AM, Sayanee Basu notifications@github.com wrote:
Side note: This will be a major version upgrade with respect to semantic versioning http://semver.org/.
MAJOR version when you make incompatible API changes
— Reply to this email directly or view it on GitHub https://github.com/webuildsg/webuild/issues/58#issuecomment-54240884.
I think this is new enough to make a breaking change. I don't think there is ANY service depending on us currently. I understand that it's a bad idea to do it this way, but if we do this soon, we can get away with it, and reduce the ugliness in the code.
I love that you're both putting so much thought into clean code, clean design, following standards whenever possible, cleaning up earlier hacks, etc. Shows professionalism. :+1:
@cbas - isn't that what open source side projects are for? :tada: Best way to learn and make friends :+1:
clean code, clean design, following standards whenever possible, cleaning up earlier hacks
Side projects are for making clean code, professional software development and learning proper techniques..
Day job code can be a stinking mess.. who cares.. :P
LOL :open_mouth: :open_mouth:
Before I keep forgetting, big thanks to @kaihendry for first suggesting the API endpoint change to YYYY-MM-DD
:calendar: :clap:
WIP:
XX-YY-ZZZZ date formats can confuse the Americans. It's safer to use the XXXX-YY-ZZ format.