在安卓机器上，picker[mode=date]可以选择出2019-09-31这样不存在的日期。复现步骤如下： 1、导入代码片段：https://developers.weixin.qq.com/s/csMN64ml7WbZ，设置APPID：wxcaab467f182c77ed 2、点击真机调试，在安卓机器上运行该代码片段 3、在“日期选择器”部分，先选择2020-08-31，然后把2020调整为2019，这时08会自动变成09，但是31不会动，结果就成了2019-09-31 下面是截图 [图片]

审核类型：新增订阅消息的申请审核 提审时间：2019-11-06 拒绝时间：2019-11-07 拒绝信息：标题为“签到提醒”的模板消息审核不通过，原因是：关键词参数类型选择不正确，关键词“活动日期”请选择到“日期”参数类型；关键词“签到时间”请选择到“时间”参数类型 疑问：申请中的“活动日期”是一个日期范围，类似“2019/10/11~2019/11/11”，而不是一个单独的日期。这时如果选择日期类型，接口调用会不会无法通过？ 其他疑问：所有参数类型中，允许出现汉字的，最长的就是thing，接收20个以内的汉字。但是无论是投票活动、问卷活动、签到活动，活动标题经常会超过20个汉字，使得使用时候不得不做截断处理。这个20字的要求是否太严格了，设置为50字是否更合理？（比如“全国人民代表大会第17届第三次全体会议投票活动”这就超出20个字了，但是这种活动标题太常见了）

假设picker[mode=date]设置起始日期为2019-09-01，然后将日期调整到2020-08-31。如下图所示： [图片] 然后，将2020调整为2019，这时直接结果是2019-08-31，但是因为我们设置了起始日期是2019-09-01，所以这个组件自动地给月份增加了1，变成了2019-09-31，以便大于我们提供的起始日期。但是2019-09-31是一个不存在的日期。所以这里应该是有bug的。选择后的结果见下图 [图片]

- 物流助手顺丰接口下单，报错如下： {'delivery_resultcode': -1, 'errmsg': 'delivery logic fail', 'errcode': 9300501, 'waybill_data': [], 'delivery_resultmsg': 'success'} 报错码意思是快递侧错误，快递测返回码-1，然后返回信息是success。虽然明显还是出错了，但是这个返回信息success，让我们没法推测是哪里错了？ - 下面是我们提交的请求参数 {'biz_id': '5941987105',  'cargo': {'count': 2,            'detail_list': [{'count': 2, 'name': '童年小食品发糕'}],            'space_x': 20,            'space_y': 40,            'space_z': 5,            'weight': 0.8},  'delivery_id': 'SF',  'insured': {'insured_value': 0, 'use_insured': 0},  'openid': 'oVkLc4mzzcCQAlnrBBl9banoFMUo',  'order_id': '2018198329849385',  'receiver': {'address': '八一七北路133号',               'area': '鼓楼区',               'city': '福州市',               'country': '中国',               'mobile': '18171777351',               'name': '刘聪',               'province': '福建省'},  'sender': {'address': '学院北路368号名城佳园1号楼1301',             'area': '城厢区',             'city': '莆田市',             'company': '莆田市乐购网电子商务有限公司',             'country': '中国',             'name': '曾彬彬',             'post_code': '351100',             'province': '福建省',             'tel': '05941120260'},  'service': {'service_name': '顺丰标快', 'service_type': 3},  'shop': {'goods_count': 2,           'goods_name': '童年小食品发糕',           'img_url': 'https://qiniumedia.freelycode.com/vcdn/vt8iqaaq58aa/clientimg/3/project/77c6901d85714dd1b89c4f0c358730fe',           'wxa_path': '/pages/order-detail/order-detail?orderId=1'}}

- 调用下单接口，一直报错address error，实在看不出地址哪里有问题 - 期望结果：下单成功 - 调用参数： {'biz_id': '5941987105',  'cargo': {'count': 2,            'detail_list': [{'count': 2, 'name': '童年小食品发糕'}],            'space_x': 20,            'space_y': 40,            'space_z': 5,            'weight': 0.8},  'delivery_id': 'SF',  'insured': {'insured_value': 0, 'use_insured': 0},  'openid': 'oVkLc4mzzcCQAlnrBBl9banoFMUo',  'order_id': '2018198329849384',  'receiver': {'address': '拱辰街道西洪北街1118号',               'area': '荔城区',               'city': '莆田市',               'country': '中国',               'mobile': '18111111111',               'name': '刘聪',               'province': '福建省'},  'sender': {'address': '学院北路368号名城佳园1号楼1301',             'area': '城厢区',             'city': '莆田市',             'country': '中国',             'name': '曾彬彬',             'province': '福建省',             'tel': '05941110280'},  'service': {'service_name': '顺丰标快', 'service_type': 3},  'shop': {'goods_count': 2,           'goods_name': '童年小食品发糕',           'img_url': 'https://qiniumedia.freelycode.com/vcdn/vt8iqaaq58aa/clientimg/3/project/77c6901d85714dd1b89c4f0c358730fe',           'wxa_path': '/pages/order-detail/order-detail?orderId=1'}} - 目前返回结果： {'errmsg': 'delivery logic fail', 'delivery_resultmsg': 'address error', 'errcode': 9300501, 'waybill_data': [], 'delivery_resultcode': 20002} 实在看不出参数有什么问题。另外地址中的name和company如果超过10个字，就会报下面这个错误。对于company公司名称大于10个字的公司，写不到10个字，则名称是错误的，大于10个字，又说参数太长，感觉无解了。 {'errmsg': 'arg size exceed limit hint: [uZBirA05135659]', 'errcode': 9300526} 这个company和name参数，文档上都说长度限制是64个字节，结果11个字就报错了，这是不是一个bug唉？

需求的场景描述 对于标准的CRUD操作页面，更新操作页面内部逻辑流程大致是这样的： a. 加载当前数据，填充到输入框中，如果是选择项填充到picker中。 b. 让用户自行修改 c. 验证用户的输入，重新提交。 其中第一步和第三步的数据格式应该尽量是一致的，即上传给后台是什么，详情加载回来应该还是什么，这样才能够反复地进行修改操作。这是前提。 在picker[mode=region]这种情况下，最合适的数据格式是区划代码，也就是字符串，而不是现在的Array。理由如下： a. 大量应用都是既有小程序、又有APP的。但是APP中使用的地址选择器，其选项及地区的文字表示和小程序是不完全相同的，这样在小程序和APP之间如果使用Array表示地址，地址就难以打通。区划代码就没有这个问题，因为区划代码是标准的，无论什么样的展示，最终都能跟区划代码对应上，这样区划代码就是小程序和APP中地址数据的标准格式。 b. 区划代码是相对稳定的。城市、地区是有可能会改名的。如果小程序地址选择器更新，那么Array拿到的数据将使得更名后的地址无法跟更名前的地址对应上。但是更名是不影响区划代码的。 c. 区划代码没有政策风险。如果没有区划代码，没人会责备你为什么不加台湾地区。等国家要求你加时，国家一定会公布对应的区划代码。 所以picker[mode=region]无论是value输入还是change后得到的输出都默认应该是区划代码，而不是Array。但是考虑到小程序已经上线，遗留问题不好处理，那么至少无论value输入还是change后得到的输出，都应该支持区划代码。现在change输出中已有区划代码，建议value输入也支持区划代码。 希望提供的能力 建议picker[mode=region]的value输入也支持区划代码。

大家有人遇到这个问题么： 从分享出去的链接或者二维码点击进入小程序，然后在该页进行分享，得到的分享信息中（群ID）encrypted_data，iv 经常解码失败，同时又不是100%解码失败（encrypted_data, iv都是有内容的，位数也对）？ 困扰了一天了，求帮助。

能否支持带参数的临时二维码？这种不在10w个限制之内，和服务号二维码类似的方式。 带参数的临时二维码是处理线下场景的重要工具。