161–170 of 175 posts
Usually in the form: '8pm Dallas time' or something like it. Really takes the complication out of DST, especially.
Earlier quoted context omitted.
Not the millionaire part, but yeah it is nice. I work to live, not live to work, and your military job sounds horrible, so I'll pass :)
Anyone who cannot tolerate getting up a little early is definitely not what the modern military is looking for. But some of us can make that sacrifice in exchange for going home early, taking proper lunch breaks, and getting paid for time spent at the gym. We hand a unit "sports" day last week. Half of my guys chose to go fishing. And, because it is summer, we have an unofficial "stand down" every other week. And goo…
>> I consider awake to mean from 8AM to 12AM, you are getting at least 8 hours of sleep, right? Must be nice to be a millionaire who works from home then stays up late every night. Is this Charlie sheen's jingle-writing character from 2 1/2 men? The rest of the working population gets up long before 8am. Work starts at 8am. School starts at 8am. Most people I know, at least those with jobs/kids, set their alarms for…
I've been up since 4:30. https://www.youtube.com/watch?v=Nakty4Qzc1g
>> I consider awake to mean from 8AM to 12AM, you are getting at least 8 hours of sleep, right? Must be nice to be a millionaire who works from home then stays up late every night. Is this Charlie sheen's jingle-writing character from 2 1/2 men? The rest of the working population gets up long before 8am. Work starts at 8am. School starts at 8am. Most people I know, at least those with jobs/kids, set their alarms for…
Earlier quoted context omitted.
The primary issue is when the day changes in the middle of the local day. Assume everyone adopts UTC. Then in California, midnight will happen at 5pm local time. * Friday UTC 2300 = local time 4pm PST - This is Friday * Saturday UTC 0100 = local time 6pm PST - Is this Saturday? * Saturday UTC 2300 = local time 4pm PST next day - This is still Saturday? When would Saturday afternoon be? We'd have to change our vocabul…
We don't have to change any vocabulary. Noon and midnight happen at different times in different places and that would be fine. We know it's fine, because that's how it currently is in China. Most servers run on UTC under the hood, and a lot of big organizations have experience already in terms of doing all timekeeping calculations in UTC. It may seem weird, but works pretty well in the long run -- and not having to…
China is fine, because the day doesn't change during daylight.
Yeah, computers should use UTC. It's easy for them to convert to/from local time for the user. This is what computers are good at.
Earlier quoted context omitted.
Why do you think it accomplishes nothing? Benefits just from communication perspective are enough to consider single timezone. > You still would have to figure out when people in SF wake up! Exactly! It is argument against multiple TZs not for it.
Think about this harder! Let's say everyone in the US was on "Eastern Standard Time". You're scheduling a meeting for eastern standard time. You still have to figure out when your San Francisco coworkers wake up, in Eastern Time! Except without timezones, you just have to remember that SF is 3-ish hours off so people wake up at 11am. If you just had timezones, you wouldn't have to keep this in your head!
With single TZ: - I need to learn when people at different location work.
With multiple, perfect TZs: - I still need to learn when people at different location work, and additionally I need to translate (or add TZ to) every clock time when communicating with those people.
Learning when people work is similar amount of work in both cases. You always have to keep at least time offsets for every city or even office. If you have multiple TZs you need to keep them and their offsets in your head.
Earlier quoted context omitted.
Think about this harder! Let's say everyone in the US was on "Eastern Standard Time". You're scheduling a meeting for eastern standard time. You still have to figure out when your San Francisco coworkers wake up, in Eastern Time! Except without timezones, you just have to remember that SF is 3-ish hours off so people wake up at 11am. If you just had timezones, you wouldn't have to keep this in your head!
I don't understand what is your point. With single TZ: - I need to learn when people at different location work. With multiple, perfect TZs: - I still need to learn when people at different location work, and additionally I need to translate (or add TZ to) every clock time when communicating with those people. Learning when people work is similar amount of work in both cases. You always have to keep at least time off…
That's not true — I can roughly assume that everyone is at work by 9am their time. I just need to know their timezone. If I didn't have a timezone, I'd have to memorize the approximate offset of every city in the US.
Earlier quoted context omitted.
No. For one, I use the ordinal date option in ISO 8601 because the whole month and day thing is stupid. Today is 2023-191. Also my watch only reads 14:28 since the date and TZ are typically implied in watches. https://en.wikipedia.org/wiki/ISO_8601 One thing for which I would advocate is removing zero based numbering from hours and minutes. Clocks reading 12:15 for 00:15 is tremendously confusing. Most human oriented…
> No. For one, I use the ordinal date option in ISO 8601 because the whole month and day thing is stupid. Apart from this being very funny and an interesting idea I have a question: how do you deal with leap years? Many important dates throughout the year (e.g. holidays, birthdays, business quarters etc.) are bound to specific days of months, do you just have to remember that all such days after February are one off…
Leap years: A sidereal year adjustment may occur on any day, there is not a requirement for it to occur on a specific day. Leap years merely have an additional day identifier in the series before returning to 001.
Anniversary events: Again, there is no requirement that the memorialization of a person or event occur on a specific month and day. Many occurrences such as Mardi Gras and Eid using a lunar calendar or the USA's Thanksgiving using the day of week.
If one wishes to commemorate an annual event at the same orbital position as when it occurred, then ordinal dates are more effective since the Gregorian calendar's fourth-year 02/29 throws off any anniversary after the first 1/6th of the year.
NB: ISO 8601 "leap week" instances occur at a different rate than leap years (a more parallel construction would be "leap week" and "leap day"). "[The] 53 week years occur on all years that have Thursday as the 1st of January and on leap years that start on Wednesday the 1st."
https://en.wikipedia.org/wiki/Leap_year
https://en.wikipedia.org/wiki/ISO_week_date
A higher order number than ordinal and cardinal is ratio. We can also express the current day as how far through the year we are. Since today is 192, it represents 52% of a year, the ratio of current day to days in the current year. Below is an example in bash.
$ date '+%j'
192
$ echo "scale=2; $(date '+%j') / $(date '+%j' -d $(date '+%Y')'-12-31')" | bc
.52