修改PostgreSQL的时区

修改postgresql.conf的如下配置项

log_timezone = 'US/Pacific'
timezone = 'US/Pacific'

修改完毕之后,重新加载配置

pg_ctl reload

参考资料

发表在 PostgreSQL | 标签为 , | 留下评论

修改操作系统时区的方法

方法一

mv /etc/timezone /etc/timezone.old
ln -s /usr/share/zoneinfo/Etc/GMT+3 /etc/timezone
hwclock -w

方法二

timedatectl set-timezone “Asia/Kolkata”

参考资料

发表在 笔记 | 留下评论

时间本地化开发规范

时间本地化,指的是IT业务系统供不同国家、地区的用户使用时,用户访问页面看到的时间要和日常的使用习惯一致,同时保证用户可以正确理解时间的含意。

从实现代价最低、实现效果最优的角度,可以制订如下开发规范:

  • UTC时间,格式如下
    • 长整型,即从1970年1月1日0时0分0秒到现在的毫秒数。
    • 字符串,即YYYY-MM-DDThh:mm:ssTZD,例如1997-07-16T19:20:30.45Z。
  • 本地化时间格式,格式如下
    • 未启用夏令时,YYYY-MM-DDThh:mm:ss.s[+|-]+hh:mm,例如1997-07-16T19:20:30+01:00。
    • 启用夏令时,YYYY-MM-DDThh:mm:ss.s[+|-]+hh:mm DST,例如1997-07-16T19:20:30+01:00 DST。
  • 使用UTC格式存储时间。
  • 系统内部各组件交互时,使用UTC时间。
  • 系统对外提供API接口时,使用UTC时间。
  • 系统提供给前端的接口,使用用户本地化时间。
  • 允许用户自定义本地时区、夏令时。用户修改相关配置时,不影响系统的正常运行。
  • 系统所在服务器,允许指定时区和夏令时。修改相关配置时,不影响系统的正常运行。

参考资料

时间,UTC,时区,夏令时。

时间格式

Formats
Different standards may need different levels of granularity in the date and time, so this profile defines six levels. Standards that reference this profile should specify one or more of these granularities. If a given standard allows more than one granularity, it should specify the meaning of the dates and times with reduced precision, for example, the result of comparing two dates with different precisions.

The formats are as follows. Exactly the components shown here must be present, with exactly this punctuation. Note that the “T” appears literally in the string, to indicate the beginning of the time element, as specified in ISO 8601.

Year: YYYY (eg 1997) Year and month: YYYY-MM (eg 1997-07) Complete date: YYYY-MM-DD (eg 1997-07-16) Complete date plus hours and minutes: YYYY-MM-DDThh:mmTZD (eg 1997-07-16T19:20+01:00) Complete date plus hours, minutes and seconds: YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00) Complete date plus hours, minutes, seconds and a decimal fraction of a second YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00) where:

YYYY = four-digit year
MM   = two-digit month (01=January, etc.)
DD   = two-digit day of month (01 through 31)
hh   = two digits of hour (00 through 23) (am/pm NOT allowed)
mm   = two digits of minute (00 through 59)
ss   = two digits of second (00 through 59)
s    = one or more digits representing a decimal fraction of a second
TZD  = time zone designator (Z or +hh:mm or -hh:mm)

This profile does not specify how many digits may be used to represent the decimal fraction of a second. An adopting standard that permits fractions of a second must specify both the minimum number of digits (a number greater than or equal to one) and the maximum number of digits (the maximum may be stated to be “unlimited”).

This profile defines two ways of handling time zone offsets:

Times are expressed in UTC (Coordinated Universal Time), with a special UTC designator (“Z”). Times are expressed in local time, together with a time zone offset in hours and minutes. A time zone offset of “+hh:mm” indicates that the date/time uses a local time zone which is “hh” hours and “mm” minutes ahead of UTC. A time zone offset of “-hh:mm” indicates that the date/time uses a local time zone which is “hh” hours and “mm” minutes behind UTC. A standard referencing this profile should permit one or both of these ways of handling time zone offsets.


Examples
1994-11-05T08:15:30-05:00 corresponds to November 5, 1994, 8:15:30 am, US Eastern Standard Time.

1994-11-05T13:15:30Z corresponds to the same instant.

ISO 8601

时区

Time zone

夏令时

Daylight saving time

发表在 笔记 | 标签为 , , | 留下评论

菊厂MDE的生存经验–方案对比

万丈高楼平地起。
无论对做技术方向、还是做管理方向,这样都有吸引力和成就感。但以现在的年代,对于一般的业务,无论业界、还是公司内部,都有一些现成的技术方案、平台可供选择。因此,工作中主要的问题不在于无方案可选,难处在于选择太多,需要具备一双慧眼从中选择一个既匹配业务、匹配团队、又匹配个人的方案。
那么,现在手头有用户的需求,也有一些可选的方案,怎么从中选择一种方案呢?
从如下几个维度进行分析:

  • 业务场景
    业务场景以我方项目为准,可以从客户诉求、业务价值、原始需求出发,整理一个相对完善的清单。如果可选集中的方案有成熟的交付案例,则可以从中提取各方案对应的清单。
  • 业务功能
    对业务场景清单的细分和分解,需要考虑客户的特点、我方项目的交付特点,整理得到功能清单。同理,可以按照类似的格式,对可选集中的方案做一次梳理。
  • 业务规格
    和功能稍有差异,主要体现容量、速度、效率等方面的要求。这类要求需要耐心和客户沟通、确认。但在MDE层面,直接面对客户的机会相对要少一些,通常可以从前述清单出发,整理出规格清单,和架构师、SE确认即可。同理,需要针对可选集中的方案,梳理相同的清单。
    举个例子,比如作为一套管理系统,要求必须容纳N个账号,其中M个账号允许同时在线。
  • 技术方案
    对于前述整理的功能,对技术组合的要求,梳理后整理成清单。同理,需要针对可选集中的方案,整理对应的清单。
  • 技术规格
    使用对应的技术方案,为满足前述的需求,可以达成的规格,需要使用的资源等,可以从场景出发,整理成几份清单。同理,可选集中的方案,由于已有成熟应用的案例,可以直接从案例中提取。
    举个例子,比如报表系统,为满足时效性的要求,可能会有不同的技术组合,那么在时间、资源方面有不同的要求,相对应的,在技术层面可以梳理出不同的规格要求。
  • 收益/代价/风险
    我们期望方案,一方面可以匹配用户的需求,另一方面照顾项目团队的感受。 满足要求的方案不能说不存在,只是多数时候需要在某些方面做一定的妥协。那么,为了满足前述要求,需要在收益/代价/风险方面,做不同的选择。因此针对可选集中的方案,从需求出发,梳理清单。

最后一步,汇总清单,罗列关注要点,从可选的方案中,挑出匹配程度最高的方案。

总结一下,关键字有,客户需求,需求场景,可选方案,重要的关注点。

发表在 工作总结 | 标签为 , | 留下评论