* Time-zone in dates @ 2015-06-26 13:40 Oleg Sivokon 2015-06-26 14:12 ` Eric S Fraga 0 siblings, 1 reply; 23+ messages in thread From: Oleg Sivokon @ 2015-06-26 13:40 UTC (permalink / raw) To: emacs-orgmode Hello, list. I was looking for a way to add time-zone to the date recrod, something like: <2015-07-05 Sun 20:00 GMT+0>. I was told that it's very likely that the functionality isn't there, so I wonder if it's really so, and if indeed so, then what would it take to add it? I've asked the same question here: http://emacs.stackexchange.com/questions/13463/specify-timezone-in-org-date-format just in case you saw it earlier. Best. Oleg ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates 2015-06-26 13:40 Time-zone in dates Oleg Sivokon @ 2015-06-26 14:12 ` Eric S Fraga 2015-06-26 14:33 ` Left Right 2015-06-26 14:38 ` J. David Boyd 0 siblings, 2 replies; 23+ messages in thread From: Eric S Fraga @ 2015-06-26 14:12 UTC (permalink / raw) To: Oleg Sivokon; +Cc: emacs-orgmode On Friday, 26 Jun 2015 at 16:40, Oleg Sivokon wrote: > Hello, list. > > I was looking for a way to add time-zone to the date recrod, something > like: <2015-07-05 Sun 20:00 GMT+0>. I was told that it's very likely > that the functionality isn't there, so I wonder if it's really so, and > if indeed so, then what would it take to add it? It is indeed so. What would it take? Somebody to program the functionality in but this is a major challenge as time stamps are a fundamental building block of org and it would likely need to be upwards compatible... -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1247-ga833d3 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates 2015-06-26 14:12 ` Eric S Fraga @ 2015-06-26 14:33 ` Left Right 2015-06-26 14:38 ` J. David Boyd 1 sibling, 0 replies; 23+ messages in thread From: Left Right @ 2015-06-26 14:33 UTC (permalink / raw) To: Oleg Sivokon, emacs-orgmode On Fri, Jun 26, 2015 at 5:12 PM, Eric S Fraga <e.fraga@ucl.ac.uk> wrote: > Somebody to program the > functionality in but this is a major challenge as time stamps are a > fundamental building block of org and it would likely need to be upwards > compatible... > -- > : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1247-ga833d3 Thanks for the info, Eric. I imagined this wouldn't be easy, but I would be interested to know whether there might be some suggestions, possibly to split the work up into stages. For example, perhaps, at first one could only live with dates typed in in that format, but the calendar wouldn't offer an interface to input them. Perhaps there could be even more fine-grained stages. I'm also not entirely sure, but I have a feeling that that might be a problem as well: does interoperability with Calc require certain date format? Would Calc have to also have to support this, once added? Thanks. Oleg ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates 2015-06-26 14:12 ` Eric S Fraga 2015-06-26 14:33 ` Left Right @ 2015-06-26 14:38 ` J. David Boyd 2015-06-26 15:10 ` Eric S Fraga 1 sibling, 1 reply; 23+ messages in thread From: J. David Boyd @ 2015-06-26 14:38 UTC (permalink / raw) To: emacs-orgmode Eric S Fraga <e.fraga@ucl.ac.uk> writes: > On Friday, 26 Jun 2015 at 16:40, Oleg Sivokon wrote: >> Hello, list. >> >> I was looking for a way to add time-zone to the date recrod, something >> like: <2015-07-05 Sun 20:00 GMT+0>. I was told that it's very likely >> that the functionality isn't there, so I wonder if it's really so, and >> if indeed so, then what would it take to add it? > > It is indeed so. What would it take? Somebody to program the > functionality in but this is a major challenge as time stamps are a > fundamental building block of org and it would likely need to be upwards > compatible... I can see that being a real pain. The simple way would 'just' be to convert everything to UTC in the background for comparison. Nothing I want to do! Dave ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates 2015-06-26 14:38 ` J. David Boyd @ 2015-06-26 15:10 ` Eric S Fraga 2015-06-26 19:20 ` Nicolas Goaziou 0 siblings, 1 reply; 23+ messages in thread From: Eric S Fraga @ 2015-06-26 15:10 UTC (permalink / raw) To: J. David Boyd; +Cc: emacs-orgmode On Friday, 26 Jun 2015 at 10:38, J. David Boyd wrote: [...] > I can see that being a real pain. The simple way would 'just' be to convert > everything to UTC in the background for comparison. Having spent a year essentially commuting between Australia and the UK a couple of years ago, I can tell you that there is no "simple" solution... :( The simplest solution for me was firstly to use org (of course :-), then put in all time stamps as "local" time and finally ensure that the time zone setting for the computer itself, e.g. a laptop, matched where I was at the time. This turns out to be more human oriented than having to worry about time zones, especially when it comes to extra complications like summer time. In practice, I do not miss having time zone information in org. YMMV, of course! -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1247-ga833d3 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates 2015-06-26 15:10 ` Eric S Fraga @ 2015-06-26 19:20 ` Nicolas Goaziou 2015-06-26 19:57 ` francois 0 siblings, 1 reply; 23+ messages in thread From: Nicolas Goaziou @ 2015-06-26 19:20 UTC (permalink / raw) To: J. David Boyd; +Cc: emacs-orgmode Hello, Eric S Fraga <e.fraga@ucl.ac.uk> writes: > In practice, I do not miss having time zone information in org. Time zone information is interesting when users of different areas are exchanging Org documents. I think it would be useful to have: - a keyword to specify time zone per document. This time zone would apply to every time stamp not defining their own time zone. Default value could be `local' so we would be backward compatible. - a way to specify a time zone per time stamp, overriding the previous keyword. I think it would require to define a proper API for timestamps in order to ensure, e.g., comparisons are done right. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates 2015-06-26 19:20 ` Nicolas Goaziou @ 2015-06-26 19:57 ` francois 2015-06-26 21:48 ` Nicolas Goaziou 2015-06-29 13:17 ` Eric S Fraga 0 siblings, 2 replies; 23+ messages in thread From: francois @ 2015-06-26 19:57 UTC (permalink / raw) To: emacs-orgmode Hello, On Fri, Jun 26, 2015 at 09:20:00PM +0200, Nicolas Goaziou wrote: > Time zone information is interesting when users of different areas are > exchanging Org documents. > > I think it would be useful to have: > > - a keyword to specify time zone per document. This time zone would > apply to every time stamp not defining their own time zone. Default > value could be `local' so we would be backward compatible. > > - a way to specify a time zone per time stamp, overriding the previous > keyword. > > I think it would require to define a proper API for timestamps in order > to ensure, e.g., comparisons are done right. Timezones are strange beasts to deal with. It is really simpler programmatically to deal with time offsets instead. The downside is that you cannot manage DST and other similar peculiarities but the API is much simpler to write. Just please don't confuse timezones and time offsets especially in documentation as it is not the same thing and it can lead to confusion. I reread from time to time this note from W3C which explains the difference and why it matters : http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e226 Regards, François ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates 2015-06-26 19:57 ` francois @ 2015-06-26 21:48 ` Nicolas Goaziou 2015-06-29 13:17 ` Eric S Fraga 1 sibling, 0 replies; 23+ messages in thread From: Nicolas Goaziou @ 2015-06-26 21:48 UTC (permalink / raw) To: francois; +Cc: emacs-orgmode Hello, francois@avalenn.eu writes: > Timezones are strange beasts to deal with. True. > It is really simpler programmatically to deal with time offsets > instead. The downside is that you cannot manage DST and other similar > peculiarities but the API is much simpler to write. However, time offsets are not very interesting. Org is (also) about appointments, deadlines... so timezones are more accurate. Also, Emacs contains "timezone.el", which, I assume, should take care of all the heavy duty concerning these beasts, as far as an API is concerned. This requires care, but it should be doable, really, don't you think? > Just please don't confuse timezones and time offsets especially in > documentation as it is not the same thing and it can lead to > confusion. > > I reread from time to time this note from W3C which explains the > difference and why it matters : > http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e226 Thank you for the reference. I didn't know about it. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates 2015-06-26 19:57 ` francois 2015-06-26 21:48 ` Nicolas Goaziou @ 2015-06-29 13:17 ` Eric S Fraga 2015-06-30 1:17 ` Nick Dokos 1 sibling, 1 reply; 23+ messages in thread From: Eric S Fraga @ 2015-06-29 13:17 UTC (permalink / raw) To: francois; +Cc: emacs-orgmode On Friday, 26 Jun 2015 at 21:57, francois@avalenn.eu wrote: [...] > It is really simpler programmatically to deal with time offsets > instead. The downside is that you cannot manage DST and other similar > peculiarities but the API is much simpler to write. Time offsets are not sufficient. My Australia experience involved me living in South Australia while working with colleagues in the UK. The time difference throughout the year was one of 8.5 hours, 9.5 hours or 10.5 hours, depending on the various switches to and from daylight savings. Very annoying and confusing to manage... To be effective and usable, org will need to incorporate time zone information. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1253-gaa9c4b ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates 2015-06-29 13:17 ` Eric S Fraga @ 2015-06-30 1:17 ` Nick Dokos 2015-06-30 7:36 ` Eric S Fraga 0 siblings, 1 reply; 23+ messages in thread From: Nick Dokos @ 2015-06-30 1:17 UTC (permalink / raw) To: emacs-orgmode Eric S Fraga <e.fraga@ucl.ac.uk> writes: > On Friday, 26 Jun 2015 at 21:57, francois@avalenn.eu wrote: > > [...] > >> It is really simpler programmatically to deal with time offsets >> instead. The downside is that you cannot manage DST and other similar >> peculiarities but the API is much simpler to write. > > Time offsets are not sufficient. My Australia experience involved me > living in South Australia while working with colleagues in the UK. The > time difference throughout the year was one of 8.5 hours, 9.5 hours or > 10.5 hours, depending on the various switches to and from daylight > savings. Very annoying and confusing to manage... > > To be effective and usable, org will need to incorporate time zone > information. The only reliable way of doing that is to use UTC as the "internal" representation and translate to/from local time on external display/input *only*. In the case of org mode, the "internal" representation is user-visible, so that can cause confusion and some head-scratching. But *any* other method is going to be a nightmare (damhikt). -- Nick ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates 2015-06-30 1:17 ` Nick Dokos @ 2015-06-30 7:36 ` Eric S Fraga 2015-06-30 15:08 ` Nick Dokos 0 siblings, 1 reply; 23+ messages in thread From: Eric S Fraga @ 2015-06-30 7:36 UTC (permalink / raw) To: Nick Dokos; +Cc: emacs-orgmode On Monday, 29 Jun 2015 at 21:17, Nick Dokos wrote: > The only reliable way of doing that is to use UTC as the "internal" > representation and translate to/from local time on external > display/input *only*. In the case of org mode, the "internal" > representation is user-visible, so that can cause confusion and some > head-scratching. But *any* other method is going to be a nightmare > (damhikt). This may be the correct approach although I worry about losing information by only storing UTC. Whether this information loss is important or not is difficult to predict. It may be of ephemeral importance only. -- : Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-1261-g304f84 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates 2015-06-30 7:36 ` Eric S Fraga @ 2015-06-30 15:08 ` Nick Dokos 2015-07-01 6:27 ` Eric S Fraga 0 siblings, 1 reply; 23+ messages in thread From: Nick Dokos @ 2015-06-30 15:08 UTC (permalink / raw) To: emacs-orgmode Eric S Fraga <e.fraga@ucl.ac.uk> writes: > On Monday, 29 Jun 2015 at 21:17, Nick Dokos wrote: >> The only reliable way of doing that is to use UTC as the "internal" >> representation and translate to/from local time on external >> display/input *only*. In the case of org mode, the "internal" >> representation is user-visible, so that can cause confusion and some >> head-scratching. But *any* other method is going to be a nightmare >> (damhikt). > > This may be the correct approach although I worry about losing > information by only storing UTC. Whether this information loss is > important or not is difficult to predict. It may be of ephemeral > importance only. In what way are you losing information? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates 2015-06-30 15:08 ` Nick Dokos @ 2015-07-01 6:27 ` Eric S Fraga 2015-07-01 10:04 ` Michael Brand 2015-07-01 15:17 ` Nick Dokos 0 siblings, 2 replies; 23+ messages in thread From: Eric S Fraga @ 2015-07-01 6:27 UTC (permalink / raw) To: Nick Dokos; +Cc: emacs-orgmode On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote: > Eric S Fraga <e.fraga@ucl.ac.uk> writes: > >> On Monday, 29 Jun 2015 at 21:17, Nick Dokos wrote: >>> The only reliable way of doing that is to use UTC as the "internal" >>> representation and translate to/from local time on external >>> display/input *only*. In the case of org mode, the "internal" >>> representation is user-visible, so that can cause confusion and some >>> head-scratching. But *any* other method is going to be a nightmare >>> (damhikt). >> >> This may be the correct approach although I worry about losing >> information by only storing UTC. Whether this information loss is >> important or not is difficult to predict. It may be of ephemeral >> importance only. > > In what way are you losing information? Sorry, should have been clear: the time zone information itself. By reducing to UTC, you lose one bit of information. Whether that matters or not in practice is not clear but I'm always uncomfortable when considering data representations that lead to information loss. I've been trying to come up with an example that would illustrate the problem but I've failed so far. Funnily enough, the one example I can think of that would be difficult to manage with UTC is the case of not wanting to specify a time zone. Somewhat contrived but, for instance, wanting to do something every morning such as brushing my teeth. This would be, say, at 7am regardless of which time zone I'm in. If this were stored in UTC, it would be at a different time depending on where I was at the time. Enough rambling for the morning. Time to get some work done! :) -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1260-gcedef7 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates 2015-07-01 6:27 ` Eric S Fraga @ 2015-07-01 10:04 ` Michael Brand 2015-07-01 11:22 ` Eric S Fraga 2015-07-07 17:14 ` Don Armstrong 2015-07-01 15:17 ` Nick Dokos 1 sibling, 2 replies; 23+ messages in thread From: Michael Brand @ 2015-07-01 10:04 UTC (permalink / raw) To: Org Mode Hi all On Wed, Jul 1, 2015 at 8:27 AM, Eric S Fraga <e.fraga@ucl.ac.uk> wrote: > On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote: >> In what way are you losing information? > > Sorry, should have been clear: the time zone information itself. By > reducing to UTC, you lose one bit of information. Whether that matters > or not in practice is not clear but I'm always uncomfortable when > considering data representations that lead to information loss. > > I've been trying to come up with an example that would illustrate the > problem but I've failed so far. As an example for the above I suggest to consider a non-stop flight with a duration of 1:31:00 from Salt Lake City UT to Phoenix AZ, both cities in different time zones, here intentionally even the same basic time zone but one with daylight saving and one without. > Funnily enough, the one example I can think of that would be difficult > to manage with UTC is the case of not wanting to specify a time > zone. Somewhat contrived but, for instance, wanting to do something > every morning such as brushing my teeth. This would be, say, at 7am > regardless of which time zone I'm in. If this were stored in UTC, it > would be at a different time depending on where I was at the time. As an example for the above I suggest to consider noon as an event bound enough to local time. Furthermore, e. g. astronomical events can serve as examples not bound to locality. Or for Eric: A telepresence meeting with the team in South Australia and the team in UK that is in one single global Org agenda file shared between the teams. 1) Current Org that supports only local time without time zone * Flight from Salt Lake City UT to Phoenix AZ <2015-07-01 Wed 10:55>--<2015-07-01 Wed 11:26> - *Problem*: Valid only in matching local time zone, here MDT and MST. * Next noon <2015-07-01 Wed 12:00> * Next new moon <2015-07-16 Thu 03:24> - *Problem*: Valid only in matching local time zone, here CEST. 2) When the Org file format would support time zones I would use * Flight from Salt Lake City UT to Phoenix AZ <2015-07-01 Wed 10:55 MDT>--<2015-07-01 Wed 11:26 MST> - *Advantage*: Visibility of the time zones where the event takes place. * Next noon <2015-07-01 Wed 12:00> * Next new moon <2015-07-16 Thu 01:24 UTC> - *Advantage*: Visibility of neutrality regarding time zones. All three examples are convertible to all local time zones. 3) When the Org file format would not support different time zones but only UTC and Org would support only conversions from and to current local time for display and input then it is not visible that departure and arrival are in different time zones and in which time zones they are * Flight from Salt Lake City UT to Phoenix AZ <2015-07-01 Wed 16:55 UTC>--<2015-07-01 Wed 18:26 UTC> * Next noon <2015-07-01 Wed 10:00 UTC> - *Problem*: Valid only in matching local time zone, here CEST. * Next new moon <2015-07-16 Thu 01:24 UTC> Time zones used in the examples - MST :: Mountain Standard Time / Mountain Time (Standard Time), UTC-0700 - MDT :: Mountain Daylight Time (Daylight Saving Time), UTC-0600 - CEST :: Central European Summer Time (Daylight Saving Time), UTC+0200 Michael ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates 2015-07-01 10:04 ` Michael Brand @ 2015-07-01 11:22 ` Eric S Fraga 2015-07-07 17:27 ` Russell Adams 2015-07-07 17:14 ` Don Armstrong 1 sibling, 1 reply; 23+ messages in thread From: Eric S Fraga @ 2015-07-01 11:22 UTC (permalink / raw) To: Michael Brand; +Cc: Org Mode Michael, thanks for some brilliant use cases! I particularly like the single event (a flight) that requires more than one time zone to make sense. My diary is chock full of cases where it looks like a flight out somewhere takes 2 hours but coming back takes 11! (strong winds ;-) -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1260-gcedef7 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates 2015-07-01 11:22 ` Eric S Fraga @ 2015-07-07 17:27 ` Russell Adams 2015-07-08 15:59 ` Don Armstrong 0 siblings, 1 reply; 23+ messages in thread From: Russell Adams @ 2015-07-07 17:27 UTC (permalink / raw) To: emacs-orgmode; +Cc: Michael Brand On Wed, Jul 01, 2015 at 12:22:43PM +0100, Eric S Fraga wrote: > Michael, > > thanks for some brilliant use cases! > > I particularly like the single event (a flight) that requires more than > one time zone to make sense. My diary is chock full of cases where it > looks like a flight out somewhere takes 2 hours but coming back takes > 11! (strong winds ;-) > > -- > : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1260-gcedef7 > I believe this doesn't disprove the need for storing in UTC. I just think it means that you need a display filter that can specify a timezone. It sounds like most of your times will be correct using your system time, and if you have something that needs to be displayed in a different timezone, specify it for that one entry. After all there's no data lost in the plane example other than the relative timezone of the observer. The duration is fixed, and the UTC times are exact. Only the observer changes timezone. ------------------------------------------------------------------ Russell Adams RLAdams@AdamsInfoServ.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint: 1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates 2015-07-07 17:27 ` Russell Adams @ 2015-07-08 15:59 ` Don Armstrong 2015-07-08 16:16 ` Russell Adams 0 siblings, 1 reply; 23+ messages in thread From: Don Armstrong @ 2015-07-08 15:59 UTC (permalink / raw) To: emacs-orgmode; +Cc: Michael Brand On Tue, 07 Jul 2015, Russell Adams wrote: > On Wed, Jul 01, 2015 at 12:22:43PM +0100, Eric S Fraga wrote: > > I particularly like the single event (a flight) that requires more than > > one time zone to make sense. My diary is chock full of cases where it > > looks like a flight out somewhere takes 2 hours but coming back takes > > 11! (strong winds ;-) > > I believe this doesn't disprove the need for storing in UTC. [...] > After all there's no data lost in the plane example other than the > relative timezone of the observer. The relative timezone of the observer is important, though, because that's how you enter the information, and it's often the most logical way to display the information. If you just store UTC there's no way to regenerate that. Though all of that said, just storing UTC is significantly easier, and while I'd love to see a complete implementation, an incomplete implementation which could be expanded to become complete would be a great advance. -- Don Armstrong http://www.donarmstrong.com This can't be happening to me. I've got tenure. -- James Hynes _Publish and Perish_ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates 2015-07-08 15:59 ` Don Armstrong @ 2015-07-08 16:16 ` Russell Adams 2015-07-08 16:40 ` Eric S Fraga 0 siblings, 1 reply; 23+ messages in thread From: Russell Adams @ 2015-07-08 16:16 UTC (permalink / raw) To: emacs-orgmode; +Cc: Michael Brand On Wed, Jul 08, 2015 at 10:59:54AM -0500, Don Armstrong wrote: > The relative timezone of the observer is important, though, because > that's how you enter the information, and it's often the most logical > way to display the information. If you just store UTC there's no way to > regenerate that. I'd suggest that the relative timezone of the observer is normally the same, and if it should differ a display override sounds appropriate. > Though all of that said, just storing UTC is significantly easier, and > while I'd love to see a complete implementation, an incomplete > implementation which could be expanded to become complete would be a > great advance. I think the question is would supporting timezones be difficult to add? Then would you store the time in UTC only, or support a full timestamp that included timezone? Finally when being displayed they can use the user's $TZ by default, and maybe a suffix of @ TZ inside the date syntax? ------------------------------------------------------------------ Russell Adams RLAdams@AdamsInfoServ.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint: 1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates 2015-07-08 16:16 ` Russell Adams @ 2015-07-08 16:40 ` Eric S Fraga 2015-07-08 17:22 ` Titus von der Malsburg 0 siblings, 1 reply; 23+ messages in thread From: Eric S Fraga @ 2015-07-08 16:40 UTC (permalink / raw) To: emacs-orgmode; +Cc: Michael Brand On Wednesday, 8 Jul 2015 at 11:16, Russell Adams wrote: [...] > Then would you store the time in UTC only, or support a full timestamp > that included timezone? > > Finally when being displayed they can use the user's $TZ by default, > and maybe a suffix of @ TZ inside the date syntax? The ideal implementation, in my opinion, would have time stamps defined & stored with time zone information, as given by the user when creating them (although this could default to UTC, say, if not present in the time stamp) but displayed according to the user's $TZ (or overridden with emacs variable) in cases like agenda views. For upwards compatibility, however, it might be best if time stamps with no time zone information be considered to be at the user's timezone, as it is now. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1260-gcedef7 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates 2015-07-08 16:40 ` Eric S Fraga @ 2015-07-08 17:22 ` Titus von der Malsburg 0 siblings, 0 replies; 23+ messages in thread From: Titus von der Malsburg @ 2015-07-08 17:22 UTC (permalink / raw) To: Eric S Fraga; +Cc: Michael Brand, emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 1673 bytes --] On 2015-07-08 Wed 09:40, Eric S Fraga wrote: > On Wednesday, 8 Jul 2015 at 11:16, Russell Adams wrote: > > [...] > >> Then would you store the time in UTC only, or support a full timestamp >> that included timezone? >> >> Finally when being displayed they can use the user's $TZ by default, >> and maybe a suffix of @ TZ inside the date syntax? > > The ideal implementation, in my opinion, would have time stamps defined > & stored with time zone information, as given by the user when creating > them (although this could default to UTC, say, if not present in the > time stamp) but displayed according to the user's $TZ (or overridden > with emacs variable) in cases like agenda views. I like this proposal because it solves the problem at hand (as far as I can tell) but isn’t over-engineered. I also like that the date string that the user sees would be the string stored in the file, at least in the default case (non-agenda view). The mostly literal display of files is what sets org-mode apart from other outlines because that allows users to take full advantage of Emacs’ powerful text editing capabilities. > For upwards compatibility, however, it might be best if time stamps with > no time zone information be considered to be at the user's timezone, > as it is now. This point is important. Whatever the solution is it should not break documents and workflows for users who don’t care about time zones. I agree that time zones are important for some people but let’s face it, org-mode made it thus far without support time zones, which suggests that it’s not that big of a deal for most users. Titus [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 472 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates 2015-07-01 10:04 ` Michael Brand 2015-07-01 11:22 ` Eric S Fraga @ 2015-07-07 17:14 ` Don Armstrong 1 sibling, 0 replies; 23+ messages in thread From: Don Armstrong @ 2015-07-07 17:14 UTC (permalink / raw) To: emacs-orgmode On Wed, 01 Jul 2015, Michael Brand wrote: > On Wed, Jul 1, 2015 at 8:27 AM, Eric S Fraga <e.fraga@ucl.ac.uk> wrote: > > On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote: > >> In what way are you losing information? > > > > Sorry, should have been clear: the time zone information itself. By > > reducing to UTC, you lose one bit of information. Whether that matters > > or not in practice is not clear but I'm always uncomfortable when > > considering data representations that lead to information loss. > > > > I've been trying to come up with an example that would illustrate the > > problem but I've failed so far. > > As an example for the above I suggest to consider a non-stop flight > with a duration of 1:31:00 from Salt Lake City UT to Phoenix AZ, both > cities in different time zones, here intentionally even the same basic > time zone but one with daylight saving and one without. [...] > 2) When the Org file format would support time zones I would use > > * Flight from Salt Lake City UT to Phoenix AZ > <2015-07-01 Wed 10:55 MDT>--<2015-07-01 Wed 11:26 MST> > - *Advantage*: Visibility of the time zones where the event takes > place. Of course, this is even more complicated, as MST could mean UTC+08, UTC-07 or UTC+06:30. That said, lets not make perfect the enemy of the good. I've currently got emacs running under TZ="America/Los_Angeles" even though my machine is in TZ="America/Chicago" precisely because org mode can't yet handle this. I'd be willing to help out as much as I'm able, too. -- Don Armstrong http://www.donarmstrong.com I have no use for "before and after" pictures. I can't remember starting, and I'm never done. -- a softer world #221 http://www.asofterworld.com/index.php?id=221 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates 2015-07-01 6:27 ` Eric S Fraga 2015-07-01 10:04 ` Michael Brand @ 2015-07-01 15:17 ` Nick Dokos 2015-07-01 22:17 ` Left Right 1 sibling, 1 reply; 23+ messages in thread From: Nick Dokos @ 2015-07-01 15:17 UTC (permalink / raw) To: emacs-orgmode Eric S Fraga <e.fraga@ucl.ac.uk> writes: > On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote: >> Eric S Fraga <e.fraga@ucl.ac.uk> writes: >> >>> On Monday, 29 Jun 2015 at 21:17, Nick Dokos wrote: >>>> The only reliable way of doing that is to use UTC as the "internal" >>>> representation and translate to/from local time on external >>>> display/input *only*. In the case of org mode, the "internal" >>>> representation is user-visible, so that can cause confusion and some >>>> head-scratching. But *any* other method is going to be a nightmare >>>> (damhikt). >>> >>> This may be the correct approach although I worry about losing >>> information by only storing UTC. Whether this information loss is >>> important or not is difficult to predict. It may be of ephemeral >>> importance only. >> >> In what way are you losing information? > > Sorry, should have been clear: the time zone information itself. By > reducing to UTC, you lose one bit of information. Whether that matters > or not in practice is not clear but I'm always uncomfortable when > considering data representations that lead to information loss. > > I've been trying to come up with an example that would illustrate the > problem but I've failed so far. > > Funnily enough, the one example I can think of that would be difficult > to manage with UTC is the case of not wanting to specify a time > zone. Somewhat contrived but, for instance, wanting to do something > every morning such as brushing my teeth. This would be, say, at 7am > regardless of which time zone I'm in. If this were stored in UTC, it > would be at a different time depending on where I was at the time. > This is actually a pretty good example. This and Michael Brand's examples make it clear that storing (just) UTC in the file is untenable. Nick ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Time-zone in dates 2015-07-01 15:17 ` Nick Dokos @ 2015-07-01 22:17 ` Left Right 0 siblings, 0 replies; 23+ messages in thread From: Left Right @ 2015-07-01 22:17 UTC (permalink / raw) To: Nick Dokos; +Cc: emacs-orgmode My initial case was very similar to the one Michael described in the telepresence example, except that in my case, I need to assign shifts to people living in different timezones. I.e. I need to make sure that a shift assigned to someone in Illinois will end at the same time when the shift of someone from California begins. One way of doing this is to set all times in UTC+0, but some of us (especially myself :) live very close to UTC+0, so I can accidentally confuse my local time with the universal time. It would be also nicer if shifts were in the local time of people assigned to them too. On Wed, Jul 1, 2015 at 6:17 PM, Nick Dokos <ndokos@gmail.com> wrote: > Eric S Fraga <e.fraga@ucl.ac.uk> writes: > >> On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote: >>> Eric S Fraga <e.fraga@ucl.ac.uk> writes: >>> >>>> On Monday, 29 Jun 2015 at 21:17, Nick Dokos wrote: >>>>> The only reliable way of doing that is to use UTC as the "internal" >>>>> representation and translate to/from local time on external >>>>> display/input *only*. In the case of org mode, the "internal" >>>>> representation is user-visible, so that can cause confusion and some >>>>> head-scratching. But *any* other method is going to be a nightmare >>>>> (damhikt). >>>> >>>> This may be the correct approach although I worry about losing >>>> information by only storing UTC. Whether this information loss is >>>> important or not is difficult to predict. It may be of ephemeral >>>> importance only. >>> >>> In what way are you losing information? >> >> Sorry, should have been clear: the time zone information itself. By >> reducing to UTC, you lose one bit of information. Whether that matters >> or not in practice is not clear but I'm always uncomfortable when >> considering data representations that lead to information loss. >> >> I've been trying to come up with an example that would illustrate the >> problem but I've failed so far. >> >> Funnily enough, the one example I can think of that would be difficult >> to manage with UTC is the case of not wanting to specify a time >> zone. Somewhat contrived but, for instance, wanting to do something >> every morning such as brushing my teeth. This would be, say, at 7am >> regardless of which time zone I'm in. If this were stored in UTC, it >> would be at a different time depending on where I was at the time. >> > > This is actually a pretty good example. This and Michael Brand's examples > make it clear that storing (just) UTC in the file is untenable. > > Nick > > > > > ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2015-07-08 17:22 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-06-26 13:40 Time-zone in dates Oleg Sivokon 2015-06-26 14:12 ` Eric S Fraga 2015-06-26 14:33 ` Left Right 2015-06-26 14:38 ` J. David Boyd 2015-06-26 15:10 ` Eric S Fraga 2015-06-26 19:20 ` Nicolas Goaziou 2015-06-26 19:57 ` francois 2015-06-26 21:48 ` Nicolas Goaziou 2015-06-29 13:17 ` Eric S Fraga 2015-06-30 1:17 ` Nick Dokos 2015-06-30 7:36 ` Eric S Fraga 2015-06-30 15:08 ` Nick Dokos 2015-07-01 6:27 ` Eric S Fraga 2015-07-01 10:04 ` Michael Brand 2015-07-01 11:22 ` Eric S Fraga 2015-07-07 17:27 ` Russell Adams 2015-07-08 15:59 ` Don Armstrong 2015-07-08 16:16 ` Russell Adams 2015-07-08 16:40 ` Eric S Fraga 2015-07-08 17:22 ` Titus von der Malsburg 2015-07-07 17:14 ` Don Armstrong 2015-07-01 15:17 ` Nick Dokos 2015-07-01 22:17 ` Left Right
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).