在以前的Java版本中，日期和时间相关的类存在诸多问题：
- Java的日期/时间类的定义并不一致，在java.util和java.sql的包中都有日期类，此外用于格式化和解析的类在java.text包中定义。
- java.util.Date同时包含日期和时间，而java.sql.Date仅包含日期，将其纳入java.sql包并不合理。另外这两个类都有相同的名字，这本身就是一个非常糟糕的设计。
- 对于时间、时间戳、格式化以及解析，并没有一些明确定义的类。对于格式化和解析的需求，我们有java.text.DateFormat抽象类，但通常情况下，SimpleDateFormat类被用于此类需求。
- 所有的日期类都是可变的，因此他们都不是线程安全的，这是Java日期类最大的问题之一。
- 日期类并不提供国际化，没有时区支持，因此Java引入了java.util.Calendar和java.util.TimeZone类，但他们同样存在上述所有的问题。
Java 8日期/时间API是JSR-310的实现，它的实现目标是克服旧的日期时间实现中所有的缺陷，新的日期/时间API的一些设计原则是：
- 不变性：新的日期/时间API中，所有的类都是不可变的，这对多线程环境有好处。
- 关注点分离：新的API将人可读的日期时间和机器时间（unix timestamp）明确分离，它为日期（Date）、时间（Time）、日期时间（DateTime）、时间戳（unix timestamp）以及时区定义了不同的类。
- 清晰：在所有的类中，方法都被明确定义用以完成相同的行为。举个例子，要拿到当前实例我们可以使用now()方法，在所有的类中都定义了format()和parse()方法，而不是像以前那样专门有一个独立的类。为了更好的处理问题，所有的类都使用了工厂模式和策略模式，一旦你使用了其中某个类的方法，与其他类协同工作并不困难。
- 实用操作：所有新的日期/时间API类都实现了一系列方法用以完成通用的任务，如：加、减、格式化、解析、从日期/时间中提取单独部分，等等。
- 可扩展性：新的日期/时间API是工作在ISO-8601日历系统上的，但我们也可以将其应用在非IOS的日历上。
UTC的本质强调的是比GMT更为精确的世界时间标准，不过对于现行表款来说，GMT与UTC的功能与精确度是没有差别的。UTC时间+时区偏移量就是当地时间，如北京东8区（GMT+8），则UTC时间+08小时就表示北京时间。
ISO 8601 解决了很多问题，包括：
- 自然排序 - 简单和优雅，免去多余的工作即可实现排序
- 时区偏移 - 代表用户的地点和时区在日益增长的全球化和移动世界中越来越重要。
- 地区中立性 - 想象一下噩梦一般的日期 2/3/4。这个日期随着你所处美国，欧洲或者其他地方而有不同的含义...这个日期在美国代表Feb 3, 2004，或者在其他地方代表Mar 2, 2004。在ISO 8601条款中，2004-02-03去掉了这些含糊的可能性。
- 在不同的编程语言中都得到广泛的支持 - 即使不是所有的语言都使用这个标准作为默认值（例如Java），但是它们基本都有成熟的库来转化 ISO 8601格式。
一般情况下在不指定时区时，JDBC默认存储的是服务所在时区对应的时间，如果存在多个不同时区的服务会访问同一个数据库就会存在不同时区服务获取到的时间不一致问题，此时要设置JDBC的时区偏移值参数或在JDBC的URL后指定时区偏移值参数。
在第一次用HTTPS访问远程仓库时会弹出让你输入认证信息的界面，在你输入正确的用户名、密码后可访问远程仓库，但如果输错则报错无法访问，再次访问会直接报错，此时要到上面Windows凭据管理中修改认证信息，或清除已保存的凭据信息再访问时重新输入即可。