Live data from Hacker News

Show HN: Convier.me – A Calendar Service for Developers

convier.me

41–50 of 87 posts

Re: Show HN: Convier.me – A Calendar Service for Developers

#41

Nice idea, but seems to lack timezone awareness, which puts me off completely. Maybe that's being developed, but the American date format with no timezone being described as "English textual" (say what?!) seems to be ignoring all the standards for date and time (eg. RFC3339[1]), yet other parts of the docs clearly show awareness of RFCs! If you're pushing events to people, presumably you know exactly when they're goi…

Yes, I don't understand american/English dates and time. I don't know when "04/06/2019 09:00 PM" is. Is it April or June? 0900 or 2100? Let me send an ISO8601 time as all other APIs accept.

Americans use DD/MM/YYYY (regardless of delimiter being e.g. / or - or .). We Dutch use MM/DD/YYYY. The latter results in sorting correct on month if its annual data. Over multiple years it breaks. ISO 8601 has my preference, though in MS Office I need to set to Japanese cause my version lacks the setting.

9.00 PM is very clear to mean 21.00 in 24H format. What isn't clear is if 9.00 is 12H or 24H format. 9.00 AM or 9.00 PM is. However if you may reasonably assume the user uses 24H format, it is clear. It always takes up less space to use 24H format, though 12H format is always clear. Except for TZ (timezone), both all time suffers from that.

[EDIT]Oops I messed up, and that's why I dislike these and prefer ISO8601. Although one nice thing about DD/MM/YYYY is that its little endian (which is easy to remember for laymen as going from small to big). Keeping rest of comment as is.[/EDIT]

Re: Show HN: Convier.me – A Calendar Service for Developers

#42
Although I am looking for something like this,convier.me's example script didn't work for me:

curl https://convier.me/api/event \ -H 'Authorization: Bearer YEAH_SURE...' \ -d 'event[start][date]=05/26/2019 08:00 PM' \ -d 'event[end][date]=05/26/2019 11:00 PM' \ -d 'event[organizer][name]=Tony Stark' \ -d 'event[organizer][email]=ironman@avengers.com' \ -d 'event[summary][text]=Endgame premiere' \ -d 'event[description][text]=Bring the popcorn.' \ -d 'event[attendees][0][email]=MY_EMAIL'

(with API Token and email filled in of course) gives me

HTTP/1.0 402 Payment Required Cache-Control: no-cache, private Content-Type: application/json Date: Sat, 09 Jan 2021 12:52:48 GMT

{"error":true,"message":"SQLSTATE[42803]: Grouping error: 7 ERROR: column \"activities.created_at\" must appear in the GROUP BY clause or be used in an aggregate function\nLINE 1: ...NTH FROM created_at) as month, EXTRACT (YEAR FROM created_at...\n

Re: Show HN: Convier.me – A Calendar Service for Developers

#43
post #40

Earlier quoted context omitted.

Yes, I don't understand american/English dates and time. I don't know when "04/06/2019 09:00 PM" is. Is it April or June? 0900 or 2100? Let me send an ISO8601 time as all other APIs accept.

AM / PM clears up the 0900 vs 2100 ambiguity, but agreed re; American date formats.

For me it clears it up only 92% of the day. I couldn't tell you when 12:xx AM/PM is right now.

Re: Show HN: Convier.me – A Calendar Service for Developers

#44

Earlier quoted context omitted.

They're going to be toxic to you, in emails and on your support chat or @'ing you. They're going to drain your energy and make you upset. Nothing good will come from it.

Basically any popular SaaS in the wild today would disagree with your "Nothing good will come from it" comment as 99% of them offer some sort of free plan. It's really hard to start a service from 0 and get users to join the platform when it's new. Imagine then that there is no way for users to try out the platform before subscribing to it, uptake will be even lower. You don't have to reply to every chat and communic…

I may be naive in this, but aren't most people not assholes? Including free users. I would guess that most free users are nice enough and would appreciate the work you do. Also, making a product free is nice because if it is really cool, users will advertise for you. If I love a product I will share it. Simple.

Maybe OP is jaded because a couple of bad free users trashed his work.

Re: Show HN: Convier.me – A Calendar Service for Developers

#45
post #37

Any chance you could convert pricing to $X per 1000 requests? My previous company needed something like this (we ended up building it our selves at a whooping cost) but our needs were 50k+/mo of calendar invites.

Yes. Given the feedback so far, I will probably switch to a "pay as you grow" pricing.

Re: Show HN: Convier.me – A Calendar Service for Developers

#47

Although I am looking for something like this,convier.me's example script didn't work for me: curl https://convier.me/api/event \ -H 'Authorization: Bearer YEAH_SURE...' \ -d 'event[start][date]=05/26/2019 08:00 PM' \ -d 'event[end][date]=05/26/2019 11:00 PM' \ -d 'event[organizer][name]=Tony Stark' \ -d 'event[organizer][email]=ironman@avengers.com' \ -d 'event[summary][text]=Endgame premiere' \ -d 'event[descriptio…

Thank your for your feedback. I fixed that. Sorry about that.

Re: Show HN: Convier.me – A Calendar Service for Developers

#48
post #41

Earlier quoted context omitted.

Yes, I don't understand american/English dates and time. I don't know when "04/06/2019 09:00 PM" is. Is it April or June? 0900 or 2100? Let me send an ISO8601 time as all other APIs accept.

Americans use DD/MM/YYYY (regardless of delimiter being e.g. / or - or .). We Dutch use MM/DD/YYYY. The latter results in sorting correct on month if its annual data. Over multiple years it breaks. ISO 8601 has my preference, though in MS Office I need to set to Japanese cause my version lacks the setting. 9.00 PM is very clear to mean 21.00 in 24H format. What isn't clear is if 9.00 is 12H or 24H format. 9.00 AM or…

This is incorrect, Americans use MM/DD/YYYY, and from my understanding most of the rest of the world (I think the Netherlands too) use DD/MM/YYYY

Re: Show HN: Convier.me – A Calendar Service for Developers

#49
post #41

Earlier quoted context omitted.

Americans use DD/MM/YYYY (regardless of delimiter being e.g. / or - or .). We Dutch use MM/DD/YYYY. The latter results in sorting correct on month if its annual data. Over multiple years it breaks. ISO 8601 has my preference, though in MS Office I need to set to Japanese cause my version lacks the setting. 9.00 PM is very clear to mean 21.00 in 24H format. What isn't clear is if 9.00 is 12H or 24H format. 9.00 AM or…

This is incorrect, Americans use MM/DD/YYYY, and from my understanding most of the rest of the world (I think the Netherlands too) use DD/MM/YYYY

Lot of Asian countries use YYYY/MM/DD like China, Japan, South Korea etc.

Re: Show HN: Convier.me – A Calendar Service for Developers

#50
post #43
post #40

Earlier quoted context omitted.

AM / PM clears up the 0900 vs 2100 ambiguity, but agreed re; American date formats.

For me it clears it up only 92% of the day. I couldn't tell you when 12:xx AM/PM is right now.

PM means post meridiem. That's Latin, but you don't have to remember it. If you simply remember the P means 'post', and the 'M' means the exact middle of the day (12 noon) then you know 12 PM is 12.00 (after noon hence afternoon) and 12 AM is after midnight or 0.00 (the hour after previous day's 23.00 / 11 PM). Then you just need to remember morning is AM, afternoon is PM, evening is PM, and night is AM. That's it. Yeah, I find 24H system easier, but its what my native locale uses, so I am biased... (as is everyone else)
Post reply on HN