Dynamics CRM 后台通过组织服务获取时间字段值的准确转换
2015-10-14 15:06
302 查看
做CRM开发的都知道,在系统时间字段的处理上是有讲究的,因为数据库中存的是UTC时间,CRM的界面时间字段会根据个人设置中的时区以及格式自动调整,这是最基本的一面,那还有很多使用时间的场景,比如脚本使用ODATA调用组织服务取时间、后台代码中通过组织服务取时间、报表中通过sql取时间等等。报表是最容易理解的因为直接取得sql时间字段也就是UTC时间,那要正确显示直接加8小时就行。
这里主要说的是后台代码中通过组织服务取时间,我们先看一个我们常用的24小时制的显示时间
下图是个人选项中的时间的设置
下图是通过组织服务代码直接取出的时间,可以看到取出的也是UTC时间,如果要使用实际时间,必须得加8
那如果把时间格式调成AM/PM格式又会是怎样的呢?
你会发现取出来的还是基础的UTC时间,而数据库存储的是24小时制的,所以不管前台的时间格式如何,后台通过组织服务取出的时间都是数据库中存储的UTC时间,国内使用的话只需加8小时即可。
我们再看下利用组织服务更新时间字段是怎么样的,截图中可以看到我的测试时间字段的值和我的当前系统时间
而我直接把当前时间写入,不做任何改动
我们会看到界面显示的时间是当前时间
而数据库里存储的时间依旧是UTC时间,也就是自动的对时间做了减8处理
由上面的实验可知,在后台通过组织服务取时间的时候,直接取出的是UTC时间需加8处理,但是在更新时间的时候不需要做任何的处理。
后续博文继续更新前台javascript中通过ODATA获取的时间字段是如何做处理的。
这里主要说的是后台代码中通过组织服务取时间,我们先看一个我们常用的24小时制的显示时间
下图是个人选项中的时间的设置
下图是通过组织服务代码直接取出的时间,可以看到取出的也是UTC时间,如果要使用实际时间,必须得加8
那如果把时间格式调成AM/PM格式又会是怎样的呢?
你会发现取出来的还是基础的UTC时间,而数据库存储的是24小时制的,所以不管前台的时间格式如何,后台通过组织服务取出的时间都是数据库中存储的UTC时间,国内使用的话只需加8小时即可。
我们再看下利用组织服务更新时间字段是怎么样的,截图中可以看到我的测试时间字段的值和我的当前系统时间
而我直接把当前时间写入,不做任何改动
我们会看到界面显示的时间是当前时间
而数据库里存储的时间依旧是UTC时间,也就是自动的对时间做了减8处理
由上面的实验可知,在后台通过组织服务取时间的时候,直接取出的是UTC时间需加8处理,但是在更新时间的时候不需要做任何的处理。
后续博文继续更新前台javascript中通过ODATA获取的时间字段是如何做处理的。
相关文章推荐
- 对spring mybatis 缓存的使用
- port 443占用 端口冲突问题
- 都有哪些儿日志
- 使用QSnipps和360云盘实现多机代码片段采集
- TAILQ_QUEUE队列
- Linux内核加载过程
- iOS_XCode升级插件失效解决方法
- C++中include<> 与 include" " 的区别
- oracle 常用命令
- git强制放弃本地更改
- 电信免费手机卡iFree黄金版使用须知(二)
- 网页滚动时候清楚定时器
- 两个程序的进程间通信小结
- c++11 bind注意
- 持续集成系列
- 调试程序效率相关方法
- 第7周—项目6 停车场模拟
- 空净行业面临洗礼,谁能脱颖而出?
- python2.7安装
- -[__NSDictionaryI setObject:forKey:]: unrecognized selector sent to instance