同事提了个问题，PLSQL Developer连接Oracle 11g创建编辑job都正常，但是相同的PLSQL Developer连接Oracle 19c能创建job，但是选择编辑，就会提示如下日期格式错误，
看了一些资料，有的说是操作系统和Oracle的日期格式不同，建议修改短日期，从yyyy/M/d改为yyyy-M-d，
实际测试没用，而且相同Windows下，PLSQL Developer是同一个，如果是环境变量的问题，不应该19c错误，11g正常。
进一步观测，发现一些端倪，11g中的dba_jobs视图的last_date、next_date等字段类型是DATE，
但是19c的dba_jobs视图中last_date、next_date等字段类型是TIMESTAMP(6) WITH TIME ZONE，
显然可能是PLSQL Developer编辑job的功能，能识别DATE类型，但是不能识别TIMESTAMP，因此才显示'09-5月 -23 10.55.21.000000 上午 +08:00'这样一个时间戳类型是非法的日期。
但是此处只是影响通过PLSQL Developer编辑job的功能，job实际的调度和执行不受影响，毕竟执行是Oracle自己的操作，和PLSQL Developer无关，因此可以通过命令行执行job的编辑操作，虽然不直观，但至少能用。
此外，碰巧看到Oracle官方文档的一个错误，就是《References》手册中关于dba_jobs的数据字典说明，从11g开始，到23c，均是相同的内容。但实际上从19c开始，dba_jobs中关于日期的字段类型都改为了TIMESTAMP(6) WITH TIME ZONE，文档没做同步的更新，最开始参考文档，没注意到这点，直到实际看了数据库中的定义，
因此，从这个案例又证明了"眼见为实"，不要仅凭借一些文档的描述，针对问题，还是要亲自论证，这才是最可靠的。当然，作为官方手册，这种小错误，还是纠正为好，毕竟文档和产品应该是一致的。
如果您认为这篇文章有些帮助，还请不吝点下文章末尾的"点赞"和"在看"，或者直接转发pyq，
近期更新的文章：
《来自二阳人的一些感想》
《Oracle中数据导出成HTML的操作实践》
《MySQL日志 - Slow Query Log慢查询日志》
《MySQL一次大量内存消耗跟踪》
《MySQL 8.0不再担心被垃圾SQL搞爆内存的新特性》
近期的热文：
《推荐一篇Oracle RAC Cache Fusion的经典论文》
《"红警"游戏开源代码带给我们的震撼》
文章分类和索引：
《公众号1200篇文章分类和索引》
