Date/Time, timezones and TDateTime on steroids

Date/Time, timezones and TDateTime on steroids
http://c4d.asuscomm.com/wordpress/2018/05/25/kbmmw-features-3-datetime/

Comments

  1. Stefan Glienke Welll the UTC value is still correct. That the local timezone may be more complex to calculate do not negate the correctness of the UTC value.

    ReplyDelete
  2. Allow me to disagree. When I schedule something for 10:00 local time it does not matter what UTC time that is. In fact storing it as UTC and calculating it back is exactly what that article was about since any change to the timezone will affect the outcome of actual time when calculated back from UTC. In order to make it 100% correct I would need to store the date of storage in order to calculate any changes to the timezone offset that might have happened in between.

    Example: let's say back in march 2018 I wanted to schedule a meeting in Pyongyang for june 1st 2018 10:00 PYT. Back in march that time would have translated to 01:30 UTC because PYT was +08:30. But since it changed now that UTC time would result in 10:30 PYT because now it is +09:00.

    ReplyDelete
  3. Stefan Glienke On the other hand, being able to say you missed a meeting because of Kim Jong-Un is rather cool.

    I think the rule of thumb here is store past times in UTC and future times in local timestamp with timezone?

    Now who wants to be the one to point out that $7,000 USD Interbase doesn't have a time/timestamp with timezone data type? :-)

    ReplyDelete

Post a Comment