* Tim Cross <theophil...@gmail.com> [2023-01-15 10:58]: > WRT future timestamps, we would probably have to take the same > approach as postgres i.e. the timezone rules in force at the time > the timestamp is created are assumed to be 'forever'. While this is > not true, it is really the only solution you can adopt and you just > have ot accept that there is the chance that the rule will change in > the future and the timestamp will then be incorrect.
Not sure if that is so. It is about representation. Database user in different time zone would see different time in his time zone, while user in other time zone would see it different. This makes more sense for people then using UTC, which is confusing for people and which would imply that people somehow have to convert UTC to their local time. Isn't it? Imagine online meeting with 2 people in different time zones, they share the Org heading with time stamp, but when user opens that Org heading in Florida, will see different time according to his time zone, while user in East Africa will see different time. Due to correct representation, both users now know when is the meeting taking place, and they meet in same time. If they would share UTC time, or any time without time zone representation, they would get time coordination difficulties. The type TIMESTAMP WITH TIME ZONE in PostgreSQL is always stored as UTC and time zone rules are not forever. The type TIMESTAMP WITH TIME ZONE automatically converts to proper time zone. One could think for Org to simply become able to designate time zone somewhere, be it generally for Org file or/and specific heading, or/and specific timestamp. Then implement function to transform time to UTC, and then use libraries or Emacs to transform UTC to designated time zone. https://www.postgresql.org/docs/15/datatype-datetime.html For timestamp with time zone, the internally stored value is always in UTC (Universal Coordinated Time, traditionally known as Greenwich Mean Time, GMT). An input value that has an explicit time zone specified is converted to UTC using the appropriate offset for that time zone. If no time zone is stated in the input string, then it is assumed to be in the time zone indicated by the system's TimeZone parameter, and is converted to UTC using the offset for the timezone zone. When a timestamp with time zone value is output, it is always converted from UTC to the current timezone zone, and displayed as local time in that zone. To see the time in another time zone, either change timezone or use the AT TIME ZONE construct (see Section 9.9.4). Conversions between timestamp without time zone and timestamp with time zone normally assume that the timestamp without time zone value should be taken or given as timezone local time. A different time zone can be specified for the conversion using AT TIME ZONE. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/
