|
Eddy Vluggen wrote: Daylight saving time needs to go away
Actually, isn't there a push to change to DST permanently?
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
The sensible thing would be to change to UTC all over the world.
Even tiny little Norway, essentially running north-to-south, 'midday' varies by two hours from east to west; yet we manage it as a single time zone. If we (at UTC+0100) call a GB contact (at UTC+0000), he won't be available until 10:00 - those Brits don't like getting out of bed early, and don't arrive at work until 09:00 local time. Here, standard office hours are from 08:00. Craftsmen and manual workers start at 07:00, at the latest - some at 06:00.
So you can't expect midday to be at 12 sharp local time. You can't expect working hours to start at 8 local time - or 9 local time. Or that bedtime is at 22:00 - the last week, my bedtime has been around 04:00 local time  . You have to attach some numeric clock value to such terms anyway, since the interpretation varies greatly even within single time zone.
Cooperation and communication across the world would be so much easier if we had one single time reference. China spans five time zones, but uses UTC+0800 all over (with no DST), for a great simplification all matters relating to time, such as schedules, meetings, communication.
Current time is nothing more than a label. What does it matter if the start of standard Norwegian office hours are relabeled from 08:00 to 07:00? It would be at the same time, just a different label!
If an Adelaide, Australia, contact today says that I can call him between eleven and twelve, I have to think: Is Adelaide in UTC+0900 or UTC+1000? No, it is UTC+0930! And they have DST at the opposite part of the year that we have. Are they still on UTC+1030? Parts of the year, they are nine an a half hours ahead of us, parts eight and a half, parts seven and a half. It would be so much simpler if he would say 'Call med between 20:30 and 21:30' - that is, in UTC time. I wouldn't have to worry about his time zone, my DST, his DST. There would be no source of misunderstanding of time indications.
|
|
|
|
|
Easier said than done. Time like temperature as it is more than just a number it's the body's sense of a measurement. That has been the resistance at least in US to the change from F to C. Our brain and body has been synced to a number that we feel or see, temperature or light.
|
|
|
|
|
Your argument can be uses against any changes in any area whatsoever. Even against dropping DST - "our brain and body has been synced to" light summer nights, dark winter nights, so we can't change that!
It also depends on how you handle the situation. Norwegian farmers blame the cows: Tomorrow morning (DST starts this night) they simply are not ready for being milked at the ordinary morning milking time, at 5am! The farmers insist on doing the milking at wall clock time 5am. They could have decided to "delay" the milking tomorrow morning, doing it at 6am - the sun would be as high on the sky at 6am as it was today at 5am, and the cows wouldn't notice that it is one hour later. But the farmers refuse to do that - then they would loose one essential argument against DST.
Your "brain and body has been synced" to the sun, not the wall clock! If your wall clock stops, your body goes on. If the body went by wall clock time, jet lag would be a non-issue. The wall clock time of dawn varies by quite a few hours over the year, but your body reacts to the dawn, not to the wall clock. Or ... Your body probably reacts to your alarm clock, but that is to the alarm, not to the dial. It really doesn't matter if the dial says 7am or 14:00 - you wake by the alarm, not the dial.
Actually, switching to UTC would be simpler in the US than e.g. in Norway. It wouldn't happen overnight; there would be a mix of 'old' and 'new' time. In the US, the difference between the two is so large that it would usually be quite obvious which scale you are on. Any hour > 12 would obviously be 'new' time, any 'am' or 'pm' would be 'old'. Here, the risk of confusion is much larger: 24h time has been commonplace for more than fifty years. We never used 'am' and 'pm', even with 12h time. The change would be only a single hour (or two, with DST), so the risk of confusion would be large during the transition period. Yet I think it would be worth it. (But I am not holding my breath for it to happen ...)
|
|
|
|
|
Yes, in the US.
But it's still not a done deal yet.
|
|
|
|
|
 same thought over here - going for UTC+1 all over the place ... and time
|
|
|
|
|
will be around 11:30 UTC.
|
|
|
|
|
How many letters is that? 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
(11,30)
Probably a Welsh town.
// TODO: Insert something here Top ten reasons why I'm lazy
1.
|
|
|
|
|
I wonder if it's near Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch(no, I totally didn't copy and paste that.)
|
|
|
|
|
|
Wordle 279 3/6
⬜⬜⬜🟨🟨
🟩🟩🟩🟨⬜
🟩🟩🟩🟩🟩
I guess I will be the first to post this everyday unless someone east of India decides to get into the act.
Even then, he will have to get up in the middle of the night to beat me!
|
|
|
|
|
Using a VPN server in New Zealand and/or changing the clock might work!
|
|
|
|
|
Nope.
The new puzzle of the day is made available in every location just after midnight local time.
One has to be in Tonga or some such place and wake up at midnight to be the first to solve the puzzle.
My sleep patterns are disturbed and I wake up around 1 am India Standard Time and, being sleepless, I solve a Sudoku puzzle and then attempt Wordle of the day.
That would be 6:30 am in Sydney. Somebody, if he is motivated enough, can get up that early and beat me to be the first one to post on CodeProject.😁😁😁
|
|
|
|
|
Wordle 279 4/6
⬜🟨🟨⬜⬜
⬜🟨⬜⬜🟨
🟨🟨🟨🟨🟨
🟩🟩🟩🟩🟩
The second yellow in position 2 made it easy to eliminate lots of possibilities
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Phew...
Wordle 279 6/6
🟨⬜⬜⬜⬜
🟨⬜🟨⬜🟨
🟩🟩🟨⬜⬜
🟩🟩⬜🟨⬜
🟩🟩⬜⬜🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
I was in class, and a classmate shared it with our teacher(btw this is a virtual school, the classroom being the "science lab") and the teacher in there was doing it. He started using WordHippo and the student started yelling "That's Cheating", and everyone agreed, including the two other teachers in the room  .
|
|
|
|
|
4 for me:
Wordle 279 4/6
⬜⬜⬜⬜🟨
⬜🟩⬜⬜⬜
🟨🟩🟨⬜⬜
🟩🟩🟩🟩🟩 Not an easy one ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
4/6
🟨⬜⬜⬜⬜
⬜🟨⬜⬜🟨
⬜⬜⬜⬜🟩
🟩🟩🟩🟩🟩
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Wordle 279 4/6
⬛⬛⬛⬛🟩
⬛⬛⬛⬛🟩
⬛🟩⬛🟨🟩
🟩🟩🟩🟩🟩
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
Wordle 279 5/6
⬜⬜⬜🟨⬜
⬜⬜🟨⬜⬜
🟨🟨🟨⬜⬜
🟨🟨⬜⬜🟨
🟩🟩🟩🟩🟩
that was close
|
|
|
|
|
I've got a beast of a piece of hardware. This little widget here:
Lilygo T5 4.7" E-Paper Device[^]
It's an all in one system, with the display panel deeply embedded into how the whole thing operates, and that's where it gets weird design-wise.
When I say deeply embedded I mean something like 14 pins on the main system are tied up to driving the display. Meanwhile, the display itself has a framebuffer which must be stored in the SoC's extended PSRAM in order to function. And finally, to drive the display requires hardware specific to the ESP32 SoC it's attached to. (Though I guess someone particularly ambitious could get it to work on a STM32 but there wouldn't be enough RAM)
There's no way I'm driving this e-paper panel outside this unit itself.
The whole thing is deeply integrated, to where it doesn't really make sense to segregate the display code from the hardware it runs on. For example, all my pin assignments can be hard coded, because they are hardwired on this device. I can assume 4MB of RAM (16 really, but 4 available under the Arduino framework), and I can make specific calls into the SoC's RTOS.
This shouldn't be causing me design issues, but every instinct in me is crying out to compartmentalize this code - like not assume pin assignments or the presence of an ESP32 WROVER, or anything like that. That's silly. I have no reason to do it. It doesn't make sense to do it. So why such a strong pull in that direction?
So I'm sitting here, tapping at VS Code in fits and starts, and I don't really know where to begin because I have to work against my instincts as a developer.
Maybe I *should* compartmentalize it just so I can operate within my normal parameters, but that would greatly complicate a lot of the code.
One problem with coding all my life is my instincts are too strong at this point.
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: Maybe I should compartmentalize it just so I can operate within my normal parameters, but that would greatly complicate a lot of the code.
But if it uncomplicates creating the code, it is worth it.
Or go all the way, and start using gotos everywhere! Once you are tired of that, you will find a happy middle ground!
|
|
|
|
|
I bounced it off someone on the esp32 subreddit and i feel a bit better about it now. I think just needed to hear another developer tell me overengineering this thing was going to be a fool's errand.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Your job sounds to me like a heck of a lot of fun. Even if you do use C++. 
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
