www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Can Walter stop living in the future? (meta)

reply WebFreak001 <d.forum webfreak.org> writes:
Hey Walter, I think you are a time traveler. [1]

this breaks the ordering in the forum, it looks weird and it 
breaks our discord bot because it's based on time. [2]

So uh can you come back to the present?

(In all seriousness, does someone know why this happens and if it 
can be fixed on the forum side? I use the RSS feed to track the 
announce forum and inside feed/entry/published the timestamp just 
for Walter just seems to have a 1 hour offset time, even though I 
take the timezone, which is -07:00h, into account. This has 
happened twice so far and I'm just assuming the published entry 
would be something controlled by the server)

[1] Screenshot on the forums: 
https://cdn.discordapp.com/attachments/242094594181955585/578111915528552449/unknown.png
[2] Broken discord news bot, posting the news 6 times because it 
is posted 1 hour in the future: https://wfr.moe/faKn9x.png
May 15
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/15/19 3:55 PM, WebFreak001 wrote:
 Hey Walter, I think you are a time traveler. [1]
 
 this breaks the ordering in the forum, it looks weird and it breaks our 
 discord bot because it's based on time. [2]
 
 So uh can you come back to the present?
 
 (In all seriousness, does someone know why this happens and if it can be 
 fixed on the forum side? I use the RSS feed to track the announce forum 
 and inside feed/entry/published the timestamp just for Walter just seems 
 to have a 1 hour offset time, even though I take the timezone, which is 
 -07:00h, into account. This has happened twice so far and I'm just 
 assuming the published entry would be something controlled by the server)
 
 [1] Screenshot on the forums: 
 https://cdn.discordapp.com/attachments/242094594181955585/5781119155
8552449/unknown.png 
 
 [2] Broken discord news bot, posting the news 6 times because it is 
 posted 1 hour in the future: https://wfr.moe/faKn9x.png
My guess, Walter was in the UK for a week, had his time set up manually, or something else, and then when came back, he didn't set the time correctly. Or his computer is set to auto-detect the time zone, and that's not working right at the moment. On the plane, I set my time manually to UK time so I could see what the time was going to be when I arrived back home. It would be cool if the server just re-timestamped things if they are so far out of date (+/- 30 minutes should be enough). I've had posts from the PAST show up, because my outbox for some reason got stuck, and I didn't notice for a few days. -Steve
May 16
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/16/2019 8:59 AM, Steven Schveighoffer wrote:
 My guess, Walter was in the UK for a week, had his time set up manually, or 
 something else, and then when came back, he didn't set the time correctly. Or 
 his computer is set to auto-detect the time zone, and that's not working right 
 at the moment.
I didn't take my desktop to the UK :-) I did discover the problem. The black hole generator I was working on as a side project had power surge, which caused a temporary rip in the space-time continuum and my house went forward an hour without my noticing. I replaced the capacitors in the power supply and things are back to normal now. Nothing to worry about.
May 16
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, May 16, 2019 at 09:21:19AM -0700, Walter Bright via Digitalmars-d wrote:
[...]
 I did discover the problem. The black hole generator I was working on
 as a side project had power surge, which caused a temporary rip in the
 space-time continuum and my house went forward an hour without my
 noticing. I replaced the capacitors in the power supply and things are
 back to normal now.  Nothing to worry about.
Did you check to make sure that the polarity hasn't been inadvertently reversed? T -- Creativity is not an excuse for sloppiness.
May 16
next sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 5/16/19 12:48 PM, H. S. Teoh wrote:
 On Thu, May 16, 2019 at 09:21:19AM -0700, Walter Bright via Digitalmars-d
wrote:
 [...]
 I did discover the problem. The black hole generator I was working on
 as a side project had power surge, which caused a temporary rip in the
 space-time continuum and my house went forward an hour without my
 noticing. I replaced the capacitors in the power supply and things are
 back to normal now.  Nothing to worry about.
Don't ya just hate when that happens?
 Did you check to make sure that the polarity hasn't been inadvertently
 reversed?
Hasn't Starfleet training taught us anything? Reversing the polarity is always the clever *solution*, not the problem!
May 16
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/16/2019 9:48 AM, H. S. Teoh wrote:
 Did you check to make sure that the polarity hasn't been inadvertently
 reversed?
Criminy! I forgot about that! Ju++s+t ++++t++++++r+y++++ng +it++++ n++++++o+w. +HH+++an+++g ++o+++n a +++mo+++++m+++en++t ............... ......... <signal lost>
May 16
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, May 16, 2019 4:47:22 PM MDT Walter Bright via Digitalmars-d 
wrote:
 On 5/16/2019 9:48 AM, H. S. Teoh wrote:
 Did you check to make sure that the polarity hasn't been inadvertently
 reversed?
Criminy! I forgot about that! Ju++s+t ++++t++++++r+y++++ng +it++++ n++++++o+w. +HH+++an+++g ++o+++n a +++mo+++++m+++en++t ............... ......... <signal lost>
Uh, oh. We really don't want to lose Walter. :) - Jonathan M Davis
May 17
prev sibling parent reply Ron Tarrant <rontarrant gmail.com> writes:
On Thursday, 16 May 2019 at 22:47:22 UTC, Walter Bright wrote:

 Criminy! I forgot about that! Ju++s+t ++++t++++++r+y++++ng 
 +it++++ n++++++o+w. +HH+++an+++g ++o+++n a +++mo+++++m+++en++t 
 ...............   ......... <signal lost>
In your avatar, I swear the tippy-top of your hair is fading away...
May 17
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/17/2019 4:45 AM, Ron Tarrant wrote:
 In your avatar, I swear the tippy-top of your hair is fading away...
It's been fading away since I was a teenager. It's nice to not have to worry anymore about hair gels, blow dryers, expensive hair cuts, bed head, helmet hair, getting it caught in the drill press, feathery creatures nesting in it, etc.
May 17
parent Ron Tarrant <rontarrant gmail.com> writes:
On Friday, 17 May 2019 at 14:16:13 UTC, Walter Bright wrote:
 On 5/17/2019 4:45 AM, Ron Tarrant wrote:
 In your avatar, I swear the tippy-top of your hair is fading 
 away...
It's been fading away since I was a teenager. It's nice to not have to worry anymore about hair gels, blow dryers, expensive hair cuts, bed head, helmet hair, getting it caught in the drill press, feathery creatures nesting in it, etc.
Wait a moment! This has nothing to do with time travel, does it!??! :)
May 18
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, May 16, 2019 at 11:59:48AM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
[...]
 It would be cool if the server just re-timestamped things if they are
 so far out of date (+/- 30 minutes should be enough). I've had posts
 from the PAST show up, because my outbox for some reason got stuck,
 and I didn't notice for a few days.
[...] Seriously, everyone should just store (and transmit) all dates in UTC always. Let the software format it according to the local timezone when it needs to be displayed. Then there would be no problems. But alas, I only dream... T -- Don't modify spaghetti code unless you can eat the consequences.
May 16
parent reply Johannes Loher <johannes.loher fg4f.de> writes:
On Thursday, 16 May 2019 at 16:46:13 UTC, H. S. Teoh wrote:
 On Thu, May 16, 2019 at 11:59:48AM -0400, Steven Schveighoffer 
 via Digitalmars-d wrote: [...]
 It would be cool if the server just re-timestamped things if 
 they are so far out of date (+/- 30 minutes should be enough). 
 I've had posts from the PAST show up, because my outbox for 
 some reason got stuck, and I didn't notice for a few days.
[...] Seriously, everyone should just store (and transmit) all dates in UTC always. Let the software format it according to the local timezone when it needs to be displayed. Then there would be no problems. But alas, I only dream... T
Unfortunately, this is actually not sufficient for all use cases. Not all dates are points in time, while dates in UTC are. E.g changes to timezones happen more often than you‘d expect. What if you set your alarm to 7:00 AM in a given timezone and then the timezone is adjusted to one hour earlier. Do you want to go your alarm to go off at 8:00 AM in that timezone now, which would be what you‘d get if the time was stored in UTC? Probably not, you want it to still go off at 7:00 AM in that timezone. Handling dates and time can be unexpectedly more difficult than one believes at first.
May 16
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 5/16/19 3:24 PM, Johannes Loher wrote:
 On Thursday, 16 May 2019 at 16:46:13 UTC, H. S. Teoh wrote:
 Seriously, everyone should just store (and transmit) all dates in UTC 
 always. Let the software format it according to the local timezone 
 when it needs to be displayed.  Then there would be no problems.
Unfortunately, this is actually not sufficient for all use cases. Not all dates are points in time, while dates in UTC are. E.g changes to timezones happen more often than you‘d expect. What if you set your alarm to 7:00 AM in a given timezone and then the timezone is adjusted to one hour earlier. Do you want to go your alarm to go off at 8:00 AM in that timezone now, which would be what you‘d get if the time was stored in UTC? Probably not, you want it to still go off at 7:00 AM in that timezone. Handling dates and time can be unexpectedly more difficult than one believes at first.
Fair point. My analysis of this: "UTC vs Local Time" is basically "absolute vs relative". UTC is a specific, unambiguous, point in time, period. Local time is UTC viewed through a chosen filter (and it's a filter that's not necessarily 1:1 (example: daylight savings time), which makes things extra fun). So the choice of "UTC vs Local" is analogous to filesystem paths (absolute vs relative paths). Accordingly, the question should be "Am I referring to a very specific, unambiguous point in time? Or am I referring to a local perspective of time?" Much like HSTeoh, I strongly suspect the vast majority of cases should be absolute time (ie, UTC, with local time being treated as a presentation-layer detail). But you bring up the idea of a user setting an alarm...and that raises an interesting wrinkle...As I see it, the problem here stems from the fact that there are potentially *TWO* different perspectives (ie "time zones") involved: (keeping in mind that "time zone" can also refer to daylight-savings status) Perspective A: The time zone (or daylight-savings status) of the user when they set the alarm. Perspective B: The time zone (or daylight-savings status) of the user when the alarm sounds. (Note that this is NOT an "absolute vs relative" distinction, but a distinction between two different relative perspectives: Kind of like "~" vs "." in filepaths.) Since all user-input involving time should naturally be considered to be relative to the user's own perspective (unless the user specifically states otherwise), this creates a dilemma because there are *two* user perspectives: Is the user entering a time relative to their current perspective ("time zone") of time? (Ie, "A"). Or are they entering a time relative to their own future self *at the moment of the alarm*? (ie, "B"). To be perfectly honest, I think any "set alarm" interface that doesn't clarify this "time-when-setting-alarm vs time-when-sounding-alarm" distinction is an inherently ambiguous interface from the user's perspective (not that most users are likely to notice this ambiguity unless its pointed out). So I agree this is a difficult situation to solve...*however*...I think it's difficult to solve *because* of competing perspectives (ie, competing local time zones and/or competing local daylight savings statuses), and NOT because of absolute ("UTC") vs relative ("local" time...but *which* local time, "upon-setting" or "upon-activation"?). Ultimately, the software (combined with its communication to the user) has to make a choice as to which user perspective the alarm's time is relative to: The user when setting the alarm, or the user when receiving the alarm. In any case, if the user's (admittedly unlikely) desire is unambiguously A: "use the user's perspective when setting the alarm", then I'll admit that despite being unlikely, the user in this case clearly *wants* to be woken at *local* 8 o'clock in your example (ie, "Activate the alarm at the point that will be 7 o'clock in the time zone I'm in right now while I'm setting the alarm"). So the time they enter should immediately be converted to UTC and stored as UTC so that later on, any current "now" local time can be converted to UTC and compared with the absolute desired point in time to determine if sounding an alarm is warranted. On the other hand, in the (more likely) case the user's desire is unambiguously B: "use the user's perspective when they are BEING AWAKENED by the alarm", then obviously it is impossible to predict the user's future time zone. Therefore, a UTC CANNOT be chosen ahead-of-time. So when the user sets the alarm, the software must store the alarm's time NOT as an unambiguous UTC, but as a time that's *relative* to whatever selected timezone (or daylight-savings status) may be "active" when the alarm is sounded. This means storing just simply a local (ie, relative, non-UTC) time and then later, upon checking whether the alarm should be sounded...converting the UTC of *now* to the time zone the user is in, and comparing *that* to the relative time ("7am"?) stored as the alarm trigger.
May 16
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, May 16, 2019 10:43:55 PM MDT Nick Sabalausky (Abscissa) via 
Digitalmars-d wrote:
 But you bring up the idea of a user setting an alarm...and that raises
 an interesting wrinkle...As I see it, the problem here stems from the
 fact that there are potentially *TWO* different perspectives (ie "time
 zones") involved: (keeping in mind that "time zone" can also refer to
 daylight-savings status)

 Perspective A: The time zone (or daylight-savings status) of the user
 when they set the alarm.

 Perspective B: The time zone (or daylight-savings status) of the user
 when the alarm sounds.

 (Note that this is NOT an "absolute vs relative" distinction, but a
 distinction between two different relative perspectives: Kind of like
 "~" vs "." in filepaths.)

 Since all user-input involving time should naturally be considered to be
 relative to the user's own perspective (unless the user specifically
 states otherwise), this creates a dilemma because there are *two* user
 perspectives: Is the user entering a time relative to their current
 perspective ("time zone") of time? (Ie, "A"). Or are they entering a
 time relative to their own future self *at the moment of the alarm*?
 (ie, "B").
A similar though subtly different use case is putting an appointment in your calendar when you're currently in a different time zone than the appointment will be. And the fact that we now carry devices in our pockets that get used for stuff like this makes it far more likely that stuff like this will come up - though it can happen without you even moving time zones. For instance, at a previous job, we were supposed to mark in Outlook when we were taking PTO, and I was in a different time zone from my eomployer. And since Outlook treated makring a day as marking a specific 24 hour period, I'd mark a day on the West Coast and end up with it showing something like 03:00 - 02:59 when folks looked at it on the East Coast. And if you didn't look at the exact times when looking at it on the calendar, I think that it managed to make it look I was taking two days off instead of one. Coming up with a way to deal with stuff like this in a way that doesn't run afoul of time zone problems can be really hard - especially since people don't tend to think about these things the same way computers do. The absolute vs relative path analogy is an interesting one though. - Jonathan M Davis
May 17
prev sibling next sibling parent Kagamin <spam here.lot> writes:
Always thought second pecision is an overkill, day number should 
be enough.
May 16
prev sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On Wed, 15 May 2019 at 17:00, WebFreak001 via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 Hey Walter, I think you are a time traveler. [1]

 this breaks the ordering in the forum, it looks weird and it
 breaks our discord bot because it's based on time. [2]

 So uh can you come back to the present?
It's you who's living in the past. :-) -- Iain
May 17