Show HN: Convier.me – A Calendar Service for Developers(convier.me)
convier.me
Show HN: Convier.me – A Calendar Service for Developers
https://convier.me
86 comments
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.
"09:00 PM" almost universally (is there any case or format or app that does it differently?) means 21:00 in 24-hour clock format. Not 09:00 (in 24-hour clock).
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)
This is in fact so simple to remember that street signs in San Francisco, where AM/PM is native, use 11:59am/pm or 12:01 and never 12:00 to avoid ambiguity. Street cleaning from 12:01am to 3:00am, for example.
Only thing to remember there is: .00 means new hour. Which the number before .00 denotes.
Caters to lowest common denominator.
I had all this explained on elementary school (which was boring and slow as fuck) during English class, and we don't even use 12H system in The Netherlands. It is quite frankly as simple to remember as a logic (tho not necessarily common) grammar rule.
Caters to lowest common denominator.
I had all this explained on elementary school (which was boring and slow as fuck) during English class, and we don't even use 12H system in The Netherlands. It is quite frankly as simple to remember as a logic (tho not necessarily common) grammar rule.
it's really weird tho
12AM 1AM 2AM 3AM 4AM ... 11AM 12PM 1PM 2PM ... 11PM 12AM 1AM
even the way you explain it:
"then you know 12 PM is 12.00 (after noon hence afternoon) "
when I read "12 after noon", I understand "noon + 12 hours" which should give midnight..
12AM 1AM 2AM 3AM 4AM ... 11AM 12PM 1PM 2PM ... 11PM 12AM 1AM
even the way you explain it:
"then you know 12 PM is 12.00 (after noon hence afternoon) "
when I read "12 after noon", I understand "noon + 12 hours" which should give midnight..
Mnemonic: “AM” is “Always Midnight”
FWIW, there's also 00:00 and 24:00 to distinguish midnight at the beginning of the day versus the end of the day.
The easy way is to remember that the hour following 12 pm is clearly in the afternoon, so 12 pm must be noon.
Yes, I'm not trying to claim that AM/PM is ambiguous, but that me as a person not used to the system (basically everyone except US and a few other countries) have no idea which is which. :)
A native Floridian once told me that the New Year's fireworks display would be starting at “12 PM”. Confused about why they’d be shooting off fireworks in the middle of the day I said, “12 PM!?” She rolled her eyes and made air quotes with her fingers and said, “Well, AM”, as if I was being extremely pedantic. To her, AM meant morning and PM meant night.
Having worked on the UI of an event-related service, I can say the error rate is much lower if you go with the ‘11:59’ workaround. In addition to the confusion about whether 12 PM is 00:00 or 12:00, there’s confusion about which calendar day 12 AM falls on. When does a Friday midnight movie start? 99.9% of people will show up at the end of Friday, but in a literal user interface you’d have to choose 12 AM Saturday. I thought of fireworks girl very frequently when I worked on that UI.
Having worked on the UI of an event-related service, I can say the error rate is much lower if you go with the ‘11:59’ workaround. In addition to the confusion about whether 12 PM is 00:00 or 12:00, there’s confusion about which calendar day 12 AM falls on. When does a Friday midnight movie start? 99.9% of people will show up at the end of Friday, but in a literal user interface you’d have to choose 12 AM Saturday. I thought of fireworks girl very frequently when I worked on that UI.
I just use noon and midnight to reduce ambiguity
11:59pm, midnight, 12:01am
11:59am, noon, 12:01pm
11:59pm, midnight, 12:01am
11:59am, noon, 12:01pm
"Midnight" doesn't solve the second part of GP's problem:
> In addition to the confusion about whether 12 PM is 00:00 or 12:00, there’s confusion about which calendar day 12 AM falls on. When does a Friday midnight movie start? 99.9% of people will show up at the end of Friday, but in a literal user interface you’d have to choose 12 AM Saturday.
I use 11:59pm or "end-of-day" for most cases.
> In addition to the confusion about whether 12 PM is 00:00 or 12:00, there’s confusion about which calendar day 12 AM falls on. When does a Friday midnight movie start? 99.9% of people will show up at the end of Friday, but in a literal user interface you’d have to choose 12 AM Saturday.
I use 11:59pm or "end-of-day" for most cases.
it is. some ppl say 2359 to avoid saying 12am/pm.
It’s June
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]
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]
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.
American software engineers use ISO8601 or RFC3339 ... I just wrote 20210108 in my journal this morning (referring to a podcast episode published yesterday).
I'll admit I might be annoying to others ... my wife is specifically irritated when I write a time in military format (but my son has no problem reading it from my phone).
I'll admit I might be annoying to others ... my wife is specifically irritated when I write a time in military format (but my son has no problem reading it from my phone).
I do that too, but I often replace the month with the 3 letter abbreviation to make it easier for others.
E.g. 2021JAN08.
E.g. 2021JAN08.
While I believe that most (?) of Europe uses DD/MM/YYYY, I am pretty sure that most of South East Asia (dunno about India and Nepal) use YYYY/MM/DD.
> I am pretty sure that most of South East Asia (dunno about India and Nepal) use YYYY/MM/DD.
I think you might have meant East Asia. I know Japan primarily uses YYYY/MM/DD.
Singapore, Malaysia, Indonesia, Thailand, Vietnam, Cambodia, Laos, Myanmar, etc (South East Asia) conventionally use DD/MM/YYYY. Interestingly, the Philippines seems to use MM/DD/YYYY.
This looks useful: https://en.wikipedia.org/wiki/Date_format_by_country
I think you might have meant East Asia. I know Japan primarily uses YYYY/MM/DD.
Singapore, Malaysia, Indonesia, Thailand, Vietnam, Cambodia, Laos, Myanmar, etc (South East Asia) conventionally use DD/MM/YYYY. Interestingly, the Philippines seems to use MM/DD/YYYY.
This looks useful: https://en.wikipedia.org/wiki/Date_format_by_country
But then in the Event section, there's a timezone ID and some talk about local time of the calendar. Maybe the other sections are behind :(
https://convier.me/docs/latest/event-component
https://convier.me/docs/latest/event-component
Thank you for your comment. There is indeed the possibility to specify the timezone, but the documentation is obviously not detailed enough on that. I'll clarify that.
You may not want to offer a free version. Freeloaders don't convert and they become a support burden whether or not you offer support to them. Once you want to shut off the free version, which you will, you're going to make those people who used your thing and didn't value it enough to pay you for it mad. They wont convert, they'll just get toxic, because they'll feel entitled to your free service. A free option isn't worth it.
You made a cool thing. Charge for it.
You made a cool thing. Charge for it.
Free users help making a robust product avoiding having tones of bugs/lacks discovered by paid users. Running an ecommerce warehouse integration platform, is not easy to come forward with all business cases / use cases beforehand. Just look below, a dude says it lacks timezone support. Valuable information. Value provided!
I agree with this advice for SaaS in general, but there are exceptions. Eg Typeform and Calendly and Dropbox all grew virally through their free tier. Given that this product is a bit similar to Calendly, perhaps a similar effect can be achieved.
Thank you for your comment. Defining the price and associated features was really not easy for me; I hesitated for a long time but you gave me some very good leads!
The problem is $9/mo is way too much for something like this unless you are using it heavily.
^^ This the kind of user you don't want. Someone who uses your service but thinks you're charging too much. You have to ignore customers like this who demand that you charge something that won't feed your employees, because there will be enough customers that will pay what you want, or you just don't have product market fit.
And with that logic you will be stuck at a small size because if you ever want to go after a larger audience you will have to cut prices to your existing customers which will be hard after you get fat and happy by over-charging.
Any publicity is good publicity. If people don’t want to pay they won’t pay, and that’s a deeper problem for your product.
Are you speaking from experience? Free users don't provide publicity, and them not converting isn't a problem with the service. You told them exactly how you valued your service and that's what they expect to pay for it. Nothing.
This is in response to toxic users. But supporting freeloaders costs money.
I’m saying weigh your conversions. Your comment suggests to discount freeloaders entirely.
I’m saying weigh your conversions. Your comment suggests to discount freeloaders entirely.
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 communication channel, especially if it's clear that you've already tried to help the user and it's not enough for them. Ignoring is a powerful tool many forget.
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 communication channel, especially if it's clear that you've already tried to help the user and it's not enough for them. Ignoring is a powerful tool many forget.
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.
Maybe OP is jaded because a couple of bad free users trashed his work.
Freeloaders are not worth it, based on my now over 10 years of experience in this space.
I hear you, we have different experiences for sure, which is why the issue is not black or white. I also have around 10 years of experience and would guess neither of my projects nor the projects I work on would be successful unless we had a free tier.
I've built a free add to calendar link generator tool, and late added an API. Costs me about 30c a month on serverless :)
https://calndr.link
Feel free to ask any questions.
Feel free to ask any questions.
This looks super useful - nice job!
Where will this be useful? I don't understand the use case
That’s exactly what I was thinking.
My first reaction was ‘this sounds like it might be useful’ but I’ve read the copy and I still don’t fully grok where I would use it effectively.
Having the curl example is good, but I feel like a few example workflow diagrams that show some cool things you build with it would be useful.
My first reaction was ‘this sounds like it might be useful’ but I’ve read the copy and I still don’t fully grok where I would use it effectively.
Having the curl example is good, but I feel like a few example workflow diagrams that show some cool things you build with it would be useful.
My guess:
Say you had a CRM app where you wanted to let users schedule sales appointments. You could use this API to send the events.
Say you had a CRM app where you wanted to let users schedule sales appointments. You could use this API to send the events.
If you’re looking for an alternative approach, I built this Add To Calendar Ruby Gem[0] which generates URLs for all the common Calendar platforms. There’s also this reference repo[1] which helps explains how to build your own and lists some other libraries in various languages.
[0] https://github.com/jaredlt/add_to_calendar
[1] https://github.com/InteractionDesignFoundation/add-event-to-...
[0] https://github.com/jaredlt/add_to_calendar
[1] https://github.com/InteractionDesignFoundation/add-event-to-...
I commented on one of your issues about all-day events; it's interesting what a hack supporting them is.
Thank you! Yeah, the ics / iCalendar part of it has a spec[0] and is reasonably easy to deal with. But Google, Yahoo and Outlook Web/Office 365 all have their own take on URL construction which can be painful!
[0] https://tools.ietf.org/html/rfc5545
[0] https://tools.ietf.org/html/rfc5545
This looks really useful. Any similar Libs. For Elixir or Javascript?
The second link I mention has some JavaScript implementations, although I have not used them myself.
https://github.com/InteractionDesignFoundation/add-event-to-...
https://github.com/InteractionDesignFoundation/add-event-to-...
In the famous words of patio11: Charge more!
(There also is outdated pricing information in your docs)
One thing that would make this really useful is a frontend widget that abstracts away many of the common complexities that arise and right now still have to be learned by everyone using this API. E.g. learning how to correctly construct recurring events and implementing a minimal UI for it would still be a pain even with this API. Algolia and their instantsearch.js (and React, etc.) packages are a great example for that where you get the faceting display logic for free.
(There also is outdated pricing information in your docs)
One thing that would make this really useful is a frontend widget that abstracts away many of the common complexities that arise and right now still have to be learned by everyone using this API. E.g. learning how to correctly construct recurring events and implementing a minimal UI for it would still be a pain even with this API. Algolia and their instantsearch.js (and React, etc.) packages are a great example for that where you get the faceting display logic for free.
"English textual datetime" as the input date format? What could go wrong... For an API this makes literally no sense.
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][email protected]' \ -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
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][email protected]' \ -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
Thank your for your feedback. I fixed that. Sorry about that.
FYI I wouldn't expose internal details like that via your responses
I love calendar tools and my friends can attest to that. I think I've built at least one calendar app every year for the past however long.
I love the idea of a calendar API (another example is Nylas - https://www.nylas.com/products/calendar-api/) b/c it means I could build for EVERYONE and not just a gsuite specific app (which is what I tend to do for simplicity of APIs). The problem I've seen with these is an inability to grow / monetize at the rate startups need to, and, while I love this, things I'm curious about are:
I love the idea of a calendar API (another example is Nylas - https://www.nylas.com/products/calendar-api/) b/c it means I could build for EVERYONE and not just a gsuite specific app (which is what I tend to do for simplicity of APIs). The problem I've seen with these is an inability to grow / monetize at the rate startups need to, and, while I love this, things I'm curious about are:
1. How big is this market?
2. Has anyone innovated on pricing here?
3. Are there really well-adopted calendar APIs you need to design for other than Exchange and GSuite?I wish this existed years ago when I had to figure out how to programmatically send out calendar invites. There were some quirks with how Outlook handled them vs Google Calendar and it was a time-consuming trial-and-error process.
Congrats on shipping!
Congrats on shipping!
Amazing, just something I was looking for recently. Would love to see a little "Update requests" on developer plan though and maybe a few more requests per month as that'd allow building an end to to end product with some headroom for developer testing.
Agree with above comments about price point being high. $9/month is high given the 500 requests limit per month
Agree with above comments about price point being high. $9/month is high given the 500 requests limit per month
1) Name is terrible. Sorry.
2) Timezone and localization support has to be spot-on, and right upfront. Might I suggest having the backend only speak UTC and the frontend has a thin layer of JS that turns all UTC into the local browser time in the onload- This design worked for me in a recent app.
2) Timezone and localization support has to be spot-on, and right upfront. Might I suggest having the backend only speak UTC and the frontend has a thin layer of JS that turns all UTC into the local browser time in the onload- This design worked for me in a recent app.
This is a great concept! Best of all you have an obvious exit strategy: Twilio and its competitors would love to add this feature set to their portfolio: imagine a txt message that not only offers to sign you up for an event, but adds it to your calendar!
To be clear: the exit strategy would be to be acquired by twilio or a competitor. One will have the foresight to add this feature then the others will feel obligated to add it too. You can position yourself to be acquired in the first round or the second.
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.
The existing tiers seem fine to me -- but I would change the name of Enterprise and make a top Enterprise tier which simply charges 1c/request, perhaps with a minimum of $50 or $100/month billed.
Not to put the project down or anything, but if you already have the ability to send transactional email, does this offer anything beyond what you could do with whatever library to generate ics attachments? Or even just generate links for various calendars? https://www.npmjs.com/package/calendar-link
What would make me definitely use this are frontend components too, like a calendar component (e.g. Vuetify's one), or especially a Calendly-like self-scheduler like the ones offered by Nylas or Kloudless, but at that point it's basically a totally different product.
What would make me definitely use this are frontend components too, like a calendar component (e.g. Vuetify's one), or especially a Calendly-like self-scheduler like the ones offered by Nylas or Kloudless, but at that point it's basically a totally different product.
In fact, not all languages have a library as simple as the Node package you are pointing at. Most libraries require you to use the iCalendar standard syntax which, for a single event, is accessible but becomes complicated for a recurring event for example.
But for the Node package you mentioned, you are absolutely right.
But for the Node package you mentioned, you are absolutely right.
Just out of curiosity, can you name one such language that doesn't have a library for generating/parsing iCal? (I assume probably the language you use for your product).
For context, we use this in production: https://www.npmjs.com/package/ical-generator, but again that's NodeJS
For context, we use this in production: https://www.npmjs.com/package/ical-generator, but again that's NodeJS
I work mostly in PHP, and when I started this project, most of the libraries were very incomplete. Customer needs led me to develop a more complete library and it's only recently that I proposed this library as an API. But, yes, much more complete and easy-to-use packages have appeared since then, although they still focus on events and don't allow to manage tasks or notes.
3 attendee max/request seems low for $9/month per user.
[deleted]
"Check the docs" button link on the landing page seems to be broken. All the best to the project!
Thank you for your comment, I fixed that.
What's the point of that illustration on the right? What purpose does it serve?
The "check the docs" button is not working next to the API request sample.
Thank you for your comment, I fixed that.
Looks useful. I’m on mobile though, and the docs aren’t mobile friendly.
It’s enterprise not entreprise. Looks interesting though.
Have you submitted to Product Hunt yet?
Not yet! With the feedbacks I just received, I want to improve the API before posting on PH.
Very nice! Good luck. Lean site.
Wonderful article. It's very useful. As a home tuition service provider, I really appreciate your post. Thanks for sharing this with us.
https://singaporetuitionteachers.com
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 going to happen, but with this API you're saying "here's an event, just pick your own timezone!"
Nice idea though, it'll be interesting to see how it develops.
[1] https://tools.ietf.org/html/rfc3339