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

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/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

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

Always thought second pecision is an overkill, day number should be enough.

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.

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.

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.

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!

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.

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>

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.