Database Timezones

Old Reflector
1

CWI wrote:

One thing we have left undone is a discussion about
times. Currently SOTA activations rely on some sort of
midnight definition (not well defined).
This works ok as all Associations are in similar
timezones. Once someone in a distinctly different time
zone joins, we will have a problem!

I’m not sure it matters that a user is in a different time zone since all times in the system are in GMT.

However, it may be a problem with summits in radically different time zone since qso will cross the midnight boundary.

I think the way forward would be to append the Associations Table with a +/- GMT field which would mean the database code would have something to work with to take this issue into consideration.

73, Jon

2

In reply to GM4ZFZ:

Would it not be possible for the site to auto adjust the time (in alerts and spots) either to local time or from local time depending on the time from the users system clock. If so it might by better to see both GMT and local time displayed in the listings. It might be difficult to set up but it would save some of the wild mistakes that people make when someone is trying to figure out what the time should be in GMT. It has happened before in the alerts in the UK where someone has put the time an hour ahead instead of behind when calculating GMT during British summer time. We should be used to it as hams but…

Regards Steve GW7AAV
http://www.gw7aav.com

3

In reply to GM4ZFZ:

Annotating the Associations with a +/- UTC field would be a start, but then we get into daylight saving issues with their start/stop dates for each Association. This is quite a complicated problem, especially so as the rule is rather loosely-defined. However, it will need addressing because doing nothing will unfairly penalise (or benefit, if played carefully) activators and chasers in far-away places. The imminent arrival of the W2 Association gives extra impetus to the discussion as UTC midnight is 7pm local there in winter and 8pm in summer - not an unreasonable time to be out on a summit.

73 de Les, G3VQO

4

In reply to G3VQO:

There was a time when radio amateurs would have been expected to be able to do simple addition and subtraction! The use of a single timeframe is actually supposed to make things easier. I think that having local and UTC displays will actually be confusing - especially as more Associations join from further away.

73

Richard
G3CWI

5

In reply to G3CWI:

I think you’re confusing my response with Steve’s. I’m not advocating displaying anything other than UTC on SOTAwatch, nor within the database. The point I’m trying (and apparently failing - hi) to make can perhaps best be illustrated by an imaginary W2ABC who wanders up to his local summit on a fine summer evening around 7.30 local. He makes a total of five QSOs over a period of one hour, so his activation should be valid. But as the five QSOs cross midnight UTC, I believe they cannot be entered in one go, at least on the one-at-a-time method. The database will then think this trip was two “failed” activations on successive days with less than four QSOs on each day.

However, his quick-witted mate at the bottom of the hill, who was the first QSO at 7.30pm, works him again at 8.30pm and gets another chaser point for “different day” UTC.

It can work for or against, but I think the problem needs addressing, albeit behind the scenes rather than as part of the SOTAwatch2 display!!

73 de Les

6

In reply to G3VQO:

In reply to G3CWI:

I think you’re confusing my response with Steve’s.

I was Les - sri!

I think the problem needs addressing,
albeit behind the scenes rather than as part of the SOTAwatch2
display!!

I does and it will be! We have been discussing the options for a while.

73

Richard

7

Greetings all–

I tried looking for more info on the activation spanning midnight UTC issue and haven’t come up with anything…has a workaround been found (besides entering fake dates and times for part of the activation to cement everything together like the following?):

HL4/W2VLA/P,23/07/10,0001,HL/JB-017,144MHz,FM,DS4OVT,REALLY 22/07@2338–500mW 59+ (to Kimje 45km)
HL4/W2VLA/P,23/07/10,0002,HL/JB-017,144MHz,FM,DS1SED/4,REALLY 22/07@2353–5W 59+ (to Jeonju 20km)
HL4/W2VLA/P,23/07/10,0024,HL/JB-017,144MHz,FM,DS5OEO,5W 54 (to KDN L2? 100km or home 50km?)
HL4/W2VLA/P,23/07/10,0043,HL/JB-017,144MHz,FM,DS4PXG/M,5W 57 (to Byeonsando 80km)
HL4/W2VLA/P,23/07/10,0117,HL/JB-017,144MHz,FM,DS4QBE/P,500mW 56 (to Iksan 35km)

Thanks and 73–

Jason HL4/W2VLA

In reply to GM4ZFZ:

CWI wrote:

One thing we have left undone is a discussion about
times. Currently SOTA activations rely on some sort of
midnight definition (not well defined).
This works ok as all Associations are in similar
timezones. Once someone in a distinctly different time
zone joins, we will have a problem!

I’m not sure it matters that a user is in a different time zone since
all times in the system are in GMT.

However, it may be a problem with summits in radically different time
zone since qso will cross the midnight boundary.

I think the way forward would be to append the Associations Table with
a +/- GMT field which would mean the database code would have
something to work with to take this issue into consideration.